How GC deal with this problem on .net platform?

Question

I have this code

 classObject var1 = new classObject();
 classObject var2 = var1;

Now, I wrote this:

 var1 = null;

How the GC will handle this ? Does GC will collect the instance of this classObject ?

And how GC will hangle this if i will wrote var2= null ? ( and remove the var1=null from the code )

This must be a duplicate. There are many questions on stackoverflow about how the GC works and how the GC knows when some object is garbage. — Steven, Jun 09 '11 at 10:29
I know about the root collection. But i still have some question .. this is not duplicate question ! — Yanshof, Jun 09 '11 at 10:30
"Does GC will collect the instance of this classObject?". The GC would be pretty flawed when it did. — Steven, Jun 09 '11 at 10:33

score 8 · Accepted Answer · answered Jun 09 '11 at 10:32

Short answer: no, because var2 still refers to the instance. As long as you have at least one reference to an object, the object will not be collected.

Longer answer: actually, probably it will in this example, because you don't go on to do anything with var2. The GC takes variable liveness into account. If you never use var2 again in the code, var2 is considered not to be live after that last line of code there. And so such a reference is considered not to be meaningful for garbage collection purposes - it's as though var2 no longer exists. So in fact, the object will be eligible for collection:

Additional subtleties: it will also depend on whether you're running in debug or release mode. When debugging, .NET artificially extends the liveness of variables to extend to the end of their lexical scope, so that you have the opportunity to inspect local variables. Also, of couse, objects will only be collected when the GC actually runs.

So strictly speaking, it's not actually possible to give on universally correct answer.

That's a helpful and elaborate answer, +1 – Zruty Jun 09 '11 at 10:35 — Zruty, Jun 09 '11 at 10:35

score 4 · Answer 2 · answered Jun 09 '11 at 10:29

4

No, because you still have a live reference to the object in var2. If you null both var1 and var2 it will become eligible for collection (assuming no further references exist).

answered Jun 09 '11 at 10:29

spender

117,338
33
229
351

The GC is even smarter than that. It MIGHT collect when there still is a reference if it can determine that the reference is never used again. – Sani Huttunen Jun 09 '11 at 10:32
I'd expect the compiler to take care of this, no? – spender Jun 09 '11 at 10:33
No, the GC can take care of it. Read the article that I link to in my answer. – jgauffin Jun 09 '11 at 10:36
Well... Both yes and no... It depends on the context and how the code is written... If all you have is the OP code then yes, the compiler should take care of it... If you have some object declaration and run a lengthy calculation (without using the reference) and then a null assignment then the GC should kick in on the reference and not the compiler... But it is a complicated process to, in each case, determine if it is the GC or compiler who will do the optmimization (if any)... – Sani Huttunen Jun 09 '11 at 10:40

jgauffin · Answer 3 · 2011-06-09T10:35:58.520

4

You still have a reference to the object (var2).

It all depends on the context.

The GC can collect objects even if you still have references to an object (if it determines that the object will not be used more in your code)

Interesting read: http://www.theserverside.net/tt/articles/showarticle.tss?id=GarbageCollection

Update

To me it sounds like you are confusing value types with reference types. When you assign a variable, you are not assigning the actual object to it, but a reference. And GC will (most times) not collect objects if a variable somewhere will have a reference to it.

Here is an article showing the difference: http://www.albahari.com/valuevsreftypes.aspx

edited Jun 09 '11 at 10:35

answered Jun 09 '11 at 10:30

jgauffin

99,844
45
235
372

Ok, and if i writine var2 = null; ( without writing var1= null; ) – Yanshof Jun 09 '11 at 10:31
It's the same, because now the reference is still held in `var1` – Daniel Hilgarth Jun 09 '11 at 10:32
1

Is this a GC feature, or a compiler opto? If object will no longer be used, I'd expect the compiler to eliminate it, but the GC? Really? – spender Jun 09 '11 at 10:32
@spender: I think this is a JIT optimization thing. The GC just looks at the references at the stack. The JIT might optimize a method in such way that the stack location is reused and in that case the object becomes eligible for collection. – Steven Jun 09 '11 at 10:36
1

@Spender: Read the answer in this SO question: http://stackoverflow.com/questions/3161119/does-the-net-garbage-collector-perform-predictive-analysis-of-code – jgauffin Jun 09 '11 at 10:40
@jhauffin: Thanks for the link. Conclusion: The JIT and GC do this together. – Steven Jun 09 '11 at 10:51

score 2 · Answer 4 · answered Jun 09 '11 at 10:30

2

You are only setting the pointer var1 to null var2 is still pointing to classObject so no GC won't collect classObject until there is at least one reference to classObject is alive

answered Jun 09 '11 at 10:30

Haris Hasan

29,856
10
92
122

score 1 · Answer 5 · answered Jun 09 '11 at 10:33

Garbage collection works by looking at the stack to determine whether objects on the heap have live references. If an object on the heap is not referenced by the stack, it is eligible for garbage collection.

You can re-assign references however many times you like, as long as an object is reachable from the stack, it will not be garbage collected!

How GC deal with this problem on .net platform?

5 Answers5

Update