Using GC Efficiently \u2013 Part 3<\/FONT><\/A> <\/SPAN>for more details on WeakReference.<\/FONT><\/P>\n <\/FONT><\/P>\nNote that the code below is only for illustration purposes \u2013 it is not necessarily what\u2019s in the production code.<\/FONT><\/P>\n <\/FONT><\/P>\nSo let\u2019s say the code used to look like this in the WeakReference class:<\/FONT><\/P>\n <\/FONT><\/P>\ninternal IntPtr m_handle;<\/SPAN><\/P>\n <\/SPAN><\/P>\npublic<\/SPAN> Object Target <\/SPAN><\/P>\n{<\/SPAN><\/P>\n <\/SPAN>get <\/SPAN><\/P>\n <\/SPAN>{<\/SPAN><\/P>\n <\/SPAN>IntPtr h = m_handle;<\/SPAN><\/P>\n <\/SPAN>if<\/SPAN> (IntPtr.Zero == h)<\/SPAN><\/P>\n <\/SPAN>return<\/SPAN> false<\/SPAN>;<\/SPAN><\/P>\n <\/SPAN><\/P>\n <\/SPAN>Object o = GCHandle.InternalGet(h);<\/SPAN><\/P>\n <\/SPAN>h = Thread.VolatileRead(ref m_handle);<\/SPAN><\/P>\n <\/SPAN>GC.KeepAlive (this<\/SPAN>);<\/SPAN><\/P>\n <\/SPAN>return<\/SPAN> (h == IntPtr.Zero) ? null : o;<\/SPAN><\/P>\n <\/SPAN>}<\/SPAN><\/P>\n <\/SPAN><\/P>\n <\/SPAN>…<\/SPAN><\/P>\n}<\/SPAN><\/P>\n <\/FONT><\/P>\nm_handle is the weak GCHandle that we create to implemente the weakref funtionality. It\u2019s a weak handle that points to the object that you want your weakref object to point to. <\/FONT><\/P>\n <\/FONT><\/P>\nThe problem is <\/FONT>Thread.VolatileRead<\/SPAN> kind of a heavy weight thing – not very performant (there was a reason why we used this API in the first place\u2026not necessarily a good one but it\u2019s what we ended up with).<\/FONT><\/P>\n <\/FONT><\/P>\nFirst of all let\u2019s take a look at the old code. Notice that we have a <\/FONT>GC.KeepAlive<\/SPAN> in there. Why would we do that? I mean if during the call of <\/FONT>Thread.VolatileRead<\/SPAN>, the weakref object is dead and its finalizer sets m_handle to 0, we\u2019d just read 0. That\u2019s fine right? <\/FONT><\/P>\n <\/FONT><\/P>\nBut imagine this code:<\/FONT><\/P>\n <\/SPAN><\/P>\nObject o = new<\/SPAN> Object(); <\/SPAN><\/P>\n <\/SPAN><\/P>\nwhile<\/SPAN> (true<\/SPAN>) <\/SPAN><\/P>\n{<\/SPAN><\/P>\n <\/SPAN>WeakReference wr = new<\/SPAN> WeakReference (o); <\/SPAN><\/P>\n <\/SPAN><\/P>\n <\/SPAN>if<\/SPAN> (wr.Target == null) <\/SPAN><\/P>\n <\/SPAN>{<\/SPAN><\/P>\n <\/SPAN>…<\/SPAN><\/P>\n <\/SPAN>}<\/SPAN><\/P>\n}<\/SPAN><\/P>\n <\/SPAN><\/P>\no.GetHashCode(); <\/SPAN><\/P>\n <\/FONT><\/P>\nWe know that o is live during the while loop which means it would be really nice if wr.Target is null (some would consider it a bug if wr.Target was ever null in this case). If we didn\u2019t have the KeepAlive, object wr could be considered dead as soon as its address is passed in to the <\/SPAN><\/FONT>Thread.VolatileRead<\/SPAN> call as the argument. So then h could be 0 and we\u2019d return null. So we want to make sure that if the object the weakref points to is guaranteed to be live during the getter call, you will always get back that object instead of null.<\/FONT><\/P>\n <\/FONT><\/P>\nWouldn\u2019t that achieve the same effect since m_handle is an instance data member and if it\u2019s used, the *this* object should be kept alive where the last statement is?<\/FONT><\/P>\n <\/FONT><\/P>\nWell, actually since m_handle is not a volatile, jit could generate some code that stores the value of m_handle in a register so it will not need to read the value of m_handle again when it\u2019s at that last statement. <\/FONT><\/P>\n <\/FONT><\/P>\nAnother interesting thing about this code is that it does the IntPtr.Zero check after it first read the value of m_handle. But how can m_handle be 0? m_handle is only set to 0 in the WeakReference class\u2019s finalizer code. If we are already KeepAlive-ing the weakref object, it means the object should be live therefore by definition the finalizer should have not been run, right?<\/FONT><\/P>\n <\/FONT><\/P>\nWell, unfortunately there is a case where m_handle can be 0 while we are in the getter which is when the getter is called in an object\u2019s finalizer. Imagine you have this object hireachy: <\/FONT><\/P>\n <\/FONT><\/P>\npublic<\/SPAN> class<\/SPAN> ObjectA<\/SPAN><\/P>\n{<\/SPAN><\/P>\n <\/SPAN>WeakReference wr;<\/SPAN><\/P>\n <\/SPAN><\/P>\n <\/SPAN>public<\/SPAN> ObjectA(WeakReference wr0)<\/SPAN><\/P>\n <\/SPAN>{<\/SPAN><\/P>\n <\/SPAN>…<\/SPAN><\/P>\n <\/SPAN>wr = wr0;<\/SPAN><\/P>\n <\/SPAN>}<\/SPAN><\/P>\n <\/SPAN><\/P>\n <\/SPAN>…<\/SPAN><\/P>\n <\/SPAN><\/P>\n <\/SPAN>public<\/SPAN> ~ObjectA() <\/SPAN><\/P>\n <\/SPAN>{<\/SPAN><\/P>\n <\/SPAN>…<\/SPAN><\/P>\n <\/SPAN>if<\/SPAN> (wr.Target == null)<\/SPAN><\/P>\n <\/SPAN>{<\/SPAN><\/P>\n <\/SPAN>…<\/SPAN><\/P>\n <\/SPAN>}<\/SPAN><\/P>\n <\/SPAN>…<\/SPAN><\/P>\n <\/SPAN>}<\/SPAN><\/P>\n}<\/SPAN><\/P>\n <\/SPAN><\/P>\nObjectA a = new<\/SPAN> ObjectA();<\/SPAN><\/P>\n <\/FONT><\/P>\nWhen a is not used anymore, at some point both a\u2019s and wr0\u2019s finalizer (assuming a is the only object that contains a reference to wr0) will be put on the finalize queue.<\/FONT><\/P>\n <\/FONT><\/P>\nNow if a\u2019s finalizer gets to run first, we are fine \u2018cause when we are in wr0\u2019s getter, m_handle is still valid. But if wr0\u2019s finalizer gets to run first, then when a\u2019s finalizer is run, m_handle is already set to 0. Of course as we\u2019ve been saying that a finalizer should do no more than releasing native resources, this shouldn\u2019t be a common scenario. <\/FONT><\/P>\n <\/FONT><\/P>\nSo, the idea is to change <\/FONT>m_handle<\/SPAN> to volatile and eliminate the need for calling <\/FONT>Thread.VolatileRead<\/SPAN>. The resulting code looks like this:<\/FONT><\/P>\n <\/FONT><\/P>\ninternal volatile<\/SPAN> IntPtr m_handle;<\/SPAN><\/P>\n <\/SPAN><\/P>\npublic<\/SPAN> Object Target <\/SPAN><\/P>\n{<\/SPAN><\/P>\n <\/SPAN>get <\/SPAN><\/P>\n