|
Scott Dorman wrote: ince large objects (greater than 85,000 bytes) don't go on the normal heap explicitly setting them to null helps the GC know that they are no longer in use.
Do you have any documentation to back that up?
AFAIK, it doesn't matter att all where the objects are allocated. The garbage collector only looks at the active references. If an inactive reference points to an object on the large objects heap, that doesn't turn it into an active reference.
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
Guffa wrote: Do you have any documentation to back that up?
Take a look at this article from Joe Duffy: http://www.bluebytesoftware.com/blog/PermaLink,guid,88e62cdf-5919-4ac7-bc33-20c06ae539ae.aspx[^]
Consider nulling out large managed object fields in your Dispose method. This is seldom necessary, but should be considered when a field is expensive to keep around, yet its owning object might be held on to longer than necessary. Simply because Dispose was called does not mean that its reference is being released. This could happen, for example, if its container (the object being disposed) is referred to from within a long-running scope (or stored in a static variable), and not explicitly nulled out. Doing this could help to reduce the lifetime of the object by making it eligible for garbage collection sooner. The definition of large and expensive is of course subjective and should be based on performance profiling and measurement. There were also a set of MSDN articles by Jeff Richter, but those appear to have been removed from the MSDN website...still looking around for other copies.
Also, take a look at this article, and specifically the comments from Wesner: http://weblogs.asp.net/pwilson/archive/2004/02/20/77422.aspx[^]
Or the second paragraph here[^]
Guffa wrote: AFAIK, it doesn't matter att all where the objects are allocated. The garbage collector only looks at the active references. If an inactive reference points to an object on the large objects heap, that doesn't turn it into an active reference.
It does matter where objects are allocated since objects in the LOB are still collected but the LOB itself is not compacted like the regular heap. I never said that "If an inactive reference points to an object on the large objects heap" it turns it into an active reference. What I did say was that you should set the large object to null, not necessarily anything that points to it.
Scott.
—In just two days, tomorrow will be yesterday.
—Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
[ Forum Guidelines] [ Articles] [ Blog]
|
|
|
|
|
Scott Dorman wrote: Take a look at this article from Joe Duffy
He's talking about setting references to null if you are going to keep the object that is containing the references. Does not apply.
Scott Dorman wrote: Also, take a look at this article, and specifically the comments from Wesner
He's talking about replacing a reference with a reference to a newly created object. Does not apply.
Scott Dorman wrote: Or the second paragraph here
He's talking about when the large objects heap is collected. Setting a reference to null doesn't change when that happens.
Scott Dorman wrote: It does matter where objects are allocated since objects in the LOB are still collected but the LOB itself is not compacted like the regular heap.
There is of course differences depending on where the object is allocated, but nothing that affects how the garbage collector finds out if the object is collectable or not.
Scott Dorman wrote: I never said that "If an inactive reference points to an object on the large objects heap" it turns it into an active reference.
You said that setting the reference to null would help the garbage collector if the object is on the large objects heap. The only way that would be helpful would be if the garbage collector treats references to large objects differently, which is doesn't.
Scott Dorman wrote: What I did say was that you should set the large object to null, not necessarily anything that points to it.
The discussion was about a collection of objects, so that's what I assumed that you were also talking about. If you are talking about something completely different, you will only be causing confusion if you don't specify what it is that you are talking about.
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
Guffa wrote: you will only be causing confusion
I'm confused - not by you Scott or Guffa - but by the conflicting info around.
Results of 'Googling' have basically said if using unmanaged memory then it should be used, if not then there's no need - but it won't hurt.
If I'm getting the last point correctly - it doesn't matter how large the Collection object is, it's the objects (items) it holds? If any of them are large then there may be a case for implementing?
If so, the point that if any of the items implement Idisposable then the collection should too means that I should implement it on any potentialy large objects and collections that may hold them?
Dave
|
|
|
|
|
DaveyM69 wrote: I'm confused - not by you Scott or Guffa - but by the conflicting info around.
Results of 'Googling' have basically said if using unmanaged memory then it should be used, if not then there's no need - but it won't hurt.
Sorry...trying to make sure I'm as clear as possible. (The conflicting information is actually what prompted my article.)
The primary purpose for the GC is to manage memory, which is actually different than managing resources. The Dispose pattern is for managing resources. That being said, the simplest rules are:
- If you are using/managing/maintaining any unmanaged memory it should be considered mandatory to use the Dispose pattern.
- If you are using/managing/maintining any objects that implement IDisposable, it should be considered mandatory to use the Dispose pattern.
- Anything else, it should be evaluated on an "as-needed" basis based on the semantics of the object and how it is intended to be used.
DaveyM69 wrote: If I'm getting the last point correctly - it doesn't matter how large the Collection object is, it's the objects (items) it holds? If any of them are large then there may be a case for implementing?
Yes, that's pretty much correct. Obviously, if the runtime allocates more than 85KB of memory to hold the actual collection object (the object itself, plus the pointers necessary for each of the "slots" in the collection) you should set it to null when you're done using the collection, but the collection itself isn't disposable per say. However, if any of the objects you maintain inside that collection implement IDisposable (or are larger than 85K themselves) you should implement IDisposable on the collection.
DaveyM69 wrote: If so, the point that if any of the items implement Idisposable then the collection should too means that I should implement it on any potentialy large objects and collections that may hold them?
Yes, that's also correct...for largely the same reasons I mentioned above.
Scott.
—In just two days, tomorrow will be yesterday.
—Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
[ Forum Guidelines] [ Articles] [ Blog]
|
|
|
|
|
Cool - I've got it 
Many thanks for all your input - and Guffa too!
Dave
|
|
|
|
|
Guffa wrote: He's talking about setting references to null if you are going to keep the object that is containing the references. Does not apply.
Yes, he is talking about setting references to null if the containing object will potentially live longer than the item. In the case of a collection, this could be the case. Consider the act of removing a collection item...the item is no longer referenced but the containing collection is.
Guffa wrote: He's talking about replacing a reference with a reference to a newly created object. Does not apply
This scenario is one of the more common causes for large amounts of memory consumption, and depending on what actions are taking place in the collection it very well may apply.
Guffa wrote: He's talking about when the large objects heap is collected. Setting a reference to null doesn't change when that happens.
True. Setting the reference to null doesn't change when anything happens. However, the LOH doesn't get compacted like the other generations. Setting the reference to null does help the GC know that you are done using the reference.
Guffa wrote: There is of course differences depending on where the object is allocated, but nothing that affects how the garbage collector finds out if the object is collectable or not.
Correct. The GC still has to walk to the heap to find objects that are no longer referenced. However, the LOH doesn't actually participate in the GC collection cycle. They are only removed if they are garbage.
Guffa wrote: You said that setting the reference to null would help the garbage collector if the object is on the large objects heap. The only way that would be helpful would be if the garbage collector treats references to large objects differently, which is doesn't.
Again, the LOH isn't part of the normal GC generations and isn't compacted. Setting the reference to null when you know the object is no longer needed can yield performance gains.
Guffa wrote: The discussion was about a collection of objects, so that's what I assumed that you were also talking about. If you are talking about something completely different, you will only be causing confusion if you don't specify what it is that you are talking about.
The discussion was about implementing IDisposable on a collection, to which my response was: If any of the collection items implement IDisposable, then yes, you definately should implement IDisposable so your collection can call Dispose on the items.
If your items are large (greater than about 85,000 bytes) you should probably still implement IDisposable, but definately make sure you set the items to null.
I don't see how that could have been any clearer.
Scott.
—In just two days, tomorrow will be yesterday.
—Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
[ Forum Guidelines] [ Articles] [ Blog]
|
|
|
|
|
Scott Dorman wrote: Yes, he is talking about setting references to null if the containing object will potentially live longer than the item. In the case of a collection, this could be the case. Consider the act of removing a collection item...the item is no longer referenced but the containing collection is.
But we are not talking about a situation where the containing object will live longer than the item. We are talking about the disposal of a collection, so the collection will not live longer than it's items.
Scott Dorman wrote: This scenario is one of the more common causes for large amounts of memory consumption, and depending on what actions are taking place in the collection it very well may apply.
It may very well happening during the use of the collection, but it has nothing at all to do with the disposal of the collection.
Scott Dorman wrote: However, the LOH doesn't get compacted like the other generations. Setting the reference to null does help the GC know that you are done using the reference.
You are repeating yourself, but you are still not explaining yourself. The GC determines if references are reachable or not, and unreachable references are not keeping objects from being collected, regardless if they are in the LOH or not. So how would the GC be helped in any way by setting a reference that is going to be unreachable to null?
Scott Dorman wrote: Again, the LOH isn't part of the normal GC generations and isn't compacted. Setting the reference to null when you know the object is no longer needed can yield performance gains.
Again, why do you think that the GC can not determine that a reference is unused by the fact that it's unreachable? How would code that uses up CPU time by doing something that is completely unnecessary help performance?
Scott Dorman wrote: The discussion was about implementing IDisposable on a collection, to which my response was:
If any of the collection items implement IDisposable, then yes, you definately should implement IDisposable so your collection can call Dispose on the items.
If your items are large (greater than about 85,000 bytes) you should probably still implement IDisposable, but definately make sure you set the items to null.
I don't see how that could have been any clearer.
It's clear what you mean, but not why you are saying it. I have already explained that setting the items in the collection to null is only a waste of time, as making the collection itself unreachable also makes all references that it contains unreachable. You are only talking about other situations where it is benificial to set references to null.
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
The collection should only implement IDisposable if the items that you store in it also implements IDisposable.
If not, there is no benefit of implementing IDisposable. At the exact moment that the collection itself is collectable, everything that it contains (that isn't referenced from anywhere else) is also collectable.
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
thanks for your advice Guffa.
Dave
|
|
|
|
|
In my main form1.cs class i am instanting another form control which has form2 title and some fields. So how can i make form2 pinned like anyothe application support this feature. I googled couldn't get much usful info may be you may show me Thanks
|
|
|
|
|
What exactly do you mean by 'pinned'?
Dave
|
|
|
|
|
I meant that I want to create the same effect a Toolbox or Properties windows provides in visual Studio. We can pinned or snap in and close them. Each window has its on title. So how can i make my form2 behave the same way in my form1. I know i got to use timer for open or closing the window but i am mostly concerned about its visual appreance and functionality. Thanks
|
|
|
|
|
This[^] may give you a starting point.
Dave
|
|
|
|
|
Hi,
I Have two tables.
Table1 has the following columns:
TableID
FieldID
FieldName
FieldValue
DateAdded
and Table2 has the following Columns
FieldID
TableID
Dataadded
And I want to display Each FieldName as a Column name for Dridview control and FieldValue as Value for each column. How can i form SELECT Statement To Achieve this ?
Thanks in advance
sri
|
|
|
|
|
Your select will give you the column names and data in the format you are looking for, you just need to bind the result to your gridview
Bob
Ashfield Consultants Ltd
|
|
|
|
|
Assalam-0-alaikum,
quite strange question. n e way, would u mind elaborating a bit more as the question is not clear.
Regards
Atif Ali Bhatti.
|
|
|
|
|
I've created a custom control named MyCs.
I added the MyCs control to My Form1 and called it MyCs1.
Now I want to add Control to MyCs1 in design mode. i.e. to drag a text box and add it to MyCs1.
(Such as what you do on panel control)
When I try it; the TextBox is added to Form1 and not to MyCs1.
Any ideas?
|
|
|
|
|
You probably need to inherit from a ContainerControl such as ContainerControl or UserControl.
|
|
|
|
|
You go leppie, keep those useless 1 answers coming.
|
|
|
|
|
Huh? 
|
|
|
|
|
Somebody una-voted you on your answer above.
|
|
|
|
|
I dont see how it was useless though...
|
|
|
|
|
Neither do I, now go Google 'sarcasm'. 
Semicolons: The number one seller of ostomy bags world wide. - dan neely
|
|
|
|
|
Hi guyz!.. i'm trying to launch an application from a service with an elevated right. THe application actually needs admin rights to lock folders and read processes on the system. The code i tried to compose works when the active session is 0 but when I lock the account under session 0 and login into another session, it launches the application on the previous account, seeing the launch program after going back to the previous account. How can i Solve this problem?.
Here is my function using createprocessasuser()
******************************************************
IntPtr l_ptrBuffer = IntPtr.Zero;
int errorCode = 0;
bool ret;
IntPtr token = new IntPtr(0);
IntPtr dupedToken = new IntPtr(0);
UInt32 dwSessionID;
SECURITY_ATTRIBUTES sa = new SECURITY_ATTRIBUTES();
sa.bInheritHandle = false;
sa.Length = Marshal.SizeOf(sa);
sa.lpSecurityDescriptor = (IntPtr)0;
PROCESS_INFORMATION pi = new PROCESS_INFORMATION();
STARTUPINFO si = new STARTUPINFO();
si.cb = Marshal.SizeOf(si);
si.lpDesktop = "winsta0\\default";
si.dwFlags = STARTF.STARTF_USESHOWWINDOW;
si.wShowWindow = ShowWindow.SW_SHOW;
this.writetolog("token b4:" + token);
dwSessionID = WTSGetActiveConsoleSessionId();
this.writetolog("from exe: " + dwSessionID.ToString());
WTS_INFO_CLASS.WTSUserName, out l_ptrBuffer, out l_nBytes);
if (!OpenProcessToken(GetCurrentProcess(), TOKEN_QUERY | TOKEN_DUPLICATE | TOKEN_ASSIGN_PRIMARY | TOKEN_ADJUST_PRIVILEGES | TOKEN_ADJUST_SESSIONID, out token))
{
this.writetolog("dili successful pag openprocesstoken");
}
this.writetolog("token mid:" + token + "current process: " + GetCurrentProcess());
const uint GENERIC_ALL = 0x10000000;
const int SecurityImpersonation = 2;
const int TokenType = 1;
ret = DuplicateTokenEx(token, GENERIC_ALL, ref sa, SecurityImpersonation, TokenType, out dupedToken);
if (ret == false)
{
this.writetolog("dili successful pag duplic8");
}
this.writetolog("duptoken b4:" + dupedToken);
SetTokenInformation(dupedToken, TOKEN_INFORMATION_CLASS.TokenSessionId, dwSessionID, (uint)IntPtr.Size);
CloseHandle(token);
ImpersonateLoggedOnUser(dupedToken);
ret = CreateProcessAsUser(dupedToken,
executable,
cmdLine,
ref sa,
ref sa,
false,
0,
(IntPtr)0,
null,
ref si,
out pi);
if (ret == false)
{
this.writetolog("ala ka create og process");
}
if (WaitForSingleObject(pi.hProcess, timeOut) != 0)
{
}
uint ec;
GetExitCodeProcess(pi.hProcess, out ec);
errorCode = (int)ec;
RevertToSelf();
CloseHandle(pi.hProcess);
CloseHandle(pi.hThread);
CloseHandle(dupedToken);
return errorCode;
******************************************************
Please help me guyz. Thankz 
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
