He’s live… he’s live not… he’s live…

re: He’s live… he’s live not… he’s live…

nativecpp — Tue, 15 May 2007 18:24:21 GMT

Thanks for the clarification.

re: He’s live… he’s live not… he’s live…

Maoni Stephens — Tue, 15 May 2007 16:20:36 GMT

nativecpp, JIT is allowed to extend the lifetime of any local to the end of the method. The C# FAQ you mentioned is incorrect. For example, JIT doesn't track all locals if there are too many (of course most methods do fall under the "not too many locals" case).

The point is you shouldn't count on JIT tracking the locals preciously. If you want to make sure a local is dead in the middle of a method you should manually set it to null. Most of the time you don't really need to do this - I would only do this if I have an object ref that associates with a lot of resources and there's a long way to go till end of the method.

re: He’s live… he’s live not… he’s live…

nativecpp — Fri, 11 May 2007 18:52:17 GMT

My other thought was that what happened when GC occurs at

m = null; // gc got triggered here

Does JIT think m is still rooted ? Or does it have a special logic to ignore this assignment and therefore m will be considered as candidate for GC ???

Thanks

re: He’s live… he’s live not… he’s live…

nativecpp — Thu, 10 May 2007 22:03:02 GMT

Yes. You are right that it is JIT not GC :-((

One of the C# FAQs (http://blogs.msdn.com/csharpfaq/archive/2004/03/26/97229.aspx) stated that there is no need to set to NULL. And yet there are some who state it should set to NULL. I always thought there is no need to set to NULL for local variables as mentioned in the FAQ. There is time when you need to set to NULL as Rico stated in the comments (http://blogs.msdn.com/ricom/archive/2003/12/04/41281.aspx).

That is why I am confused :-((

I know that you are not in JIT team. But, I thought JIT would traverse at least to the end of function block and therefore would know if the local var is reachable or NOT when GC occurs.

Thanks

re: He’s live… he’s live not… he’s live…

Maoni Stephens — Thu, 10 May 2007 00:53:09 GMT

dal, the point is you shouldn't need to worry about the object lifetime yourself (most of the time anyway) 'cause JIT will do a correct analysis and keep things that need to be live live.

nativecpp, yes, JIT (not GC :) this is not GC's job)will try very hard to determine when something is not used anymore it can be considered dead *before* it reaches the end of the scope. But it can't guarantee that as soon as something is not used anymore it can always immediately discover that. You can help JIT by settings refs to null so JIT knows immediately it can be considered dead.

re: He’s live… he’s live not… he’s live…

nativecpp — Tue, 01 May 2007 02:03:56 GMT

I meant // m is NOT referenced anymore

re: He’s live… he’s live not… he’s live…

nativecpp — Tue, 01 May 2007 02:00:37 GMT

Hi Maoni,

I was told that it is a good idea to null m before calling LongFoo. But I thought that GC can figure it out itself since m is a local var and should know that m is no longer referenced

public void foo()

{

// allocate large memory

HughMem m = new HughMem();

...

// do a long process and GC got trigger here

LongFoo();

// m is referenced anymore

...

}

re: He’s live… he’s live not… he’s live…

dal — Fri, 27 Apr 2007 12:56:09 GMT

Maoni, I thought I did understand.

I understand that currently the JIT may cache a non-volatile value in a register and not need to read it again. In this case the JIT no longer needs to have access to the underlying object from which it obtained the value, so the object does not explicitly need to be "live".

However, this is up to the JIT - it could report the object alive until after the line of code that explicitly references the object, even if the JIT does not need the object in order to determine the value of the cached item. In other words, the determination of object lifetime is up to the JIT.

IMO it ought to report the object alive until the last explicit reference to the object.

If the JIT does not report the object as live until after the last explicit reference then it makes it nearly impossible to reason about object lifetime, as developers and reviewers will need to know both the documented rules of object lifetime in .NET and the undocumented caching behavior as implemented in the JIT. This could be version sensitive, and certainly varies with debug versus release builds.

All the information I've read on object lifetime always discussed when the last reference to "this" occurred. The concern has been about when the last piece of data was extracted from "this" so that "this" was no longer needed. Adding caching behavior to this seems new to me.

I only use volatile when multiple threads may access a field for reading/writing and the variable is not protected by a lock statement; this is part of reasoning about thread safety. If I understand you correctly, this may also affect object lifetime, as a side-effect of the JIT being unable to cache the value ina a volatile field.

Please instruct me where my understanding is incomplete.

Thanks.

re: He’s live… he’s live not… he’s live…

Maoni — Thu, 19 Apr 2007 13:52:25 GMT

dal, you misunderstood. I said if m_handle is not volatile then JIT could cache the value in the register so it will not need to read it again. So the object doesn't need to be live.

re: He’s live… he’s live not… he’s live…

dal — Wed, 04 Apr 2007 14:45:18 GMT

Interesting. Couple of questions/observations...

This is nitpicking, but...

In the getter for property Target,

if (IntPtr.Zero == h)

return false;

should probably be

if (IntPtr.Zero == h)

return null;

Also, you state that if m_handle is not volatile then the jit could generate some code that caches the value of m_handle in a register, thereby subjecting it to garbage collection; thus, you simply cannot refer to m_handle after the call to Thread.VolatileRead to ensure that the "this" is kept alive till after that statement.

This may be something that we must do but I question whether we should need to do so. This requires us to have very intimate knowledge about a part of the runtime (optimizations that JIT performs) that ought to be opaque. This makes it very difficult to reason about the correctness of the code. If inspection of the code makes it appear that a reference to "this" follows a method call, then the JIT should respect that and ensure that the object is kept alive till after that LOC executes. In other words, if the JIT wants to optimize and cache values in registers, it should also insert the equivalent of logical calls to KeepAlive(this) on our behalf. We would not then need to use the volatile modifier on instance members.