Wanted GC guru

Libor Theimer

Hi,
I found the attached example (classes are not complete, but enough for explanation):

public class RegistryKey : IDisposable
{
...
[DllImport("advapi32.dll", CharSet=CharSet.Auto)]
static extern int RegDeleteKey(IntPtr hKey, string lpSubKey);

public void DeleteSubKey(string subKey)
{
// Delete the subkey
int result = RegDeleteKey(hKey, subKey);
if (result != 0)
throw new ApplicationException("Could not delete registry key: " +
ErrorHelper.GetErrorMessage(result));
}
}

A C# client might use this as follows:

public class Client
{
static readonly IntPtr HKEY_LOCAL_MACHINE =
new IntPtr(unchecked((int)0x80000002));

public static void Main()
{
RegistryKey key =
new RegistryKey(HKEY_LOCAL_MACHINE, "SOFTWARE\\.NET and COM");
key.DeleteSubKey("TemporaryKey");
}
}

with this comment:
The call to DeleteSubKeyis the last time the RegistryKeyinstance is used, and the implementation of DeleteSubKeycalls a PInvoke method with parameter types that don't keep the object alive (a simple by-value IntPtrand string). Therefore, there's a rare chance that the call to DeleteSubKey will cause an exception to be thrown. Right before the PInvoke call to RegDeleteKey, the garbage collector could free the RegistryKeyinstance because there's no further use of it anywhere in the program. (Had thisbeen passed to a PInvoke method, the instance would not be eligible for collection.) If this happens, and if the object's finalizer runs beforeRegDeleteKeyuses the HKEYpassed to it, an ApplicationExceptionwould be thrown with the message, "The handle is invalid," due to the finalizer's call to RegCloseKey.

And question is: is it possible for GC to free obj. instance inside the method of the same instance? If yes, is it the same in vb.net?

It's pretty crazy, I think...

10 Replies

Know the answer? Post it — somebody with the same question will find it here.

Vulpes12y ago
Accepted answer
To the best of my knowledge, it should not be possible for the GC to free an object whilst an instance method of that object is executing or, if it is, then it's a bug in the system.

It's certainly possible for the GC to kick in whilst such a method is executing. However, before it marks an object for garbage collection, it first needs to check the application's 'roots' to see if they refer to that object or not.

Amongst other things, an application's roots include any reference type parameters on a thread's stack. Now when an instance method is called the 'this' reference is pushed onto the stack as if it were the first of the method's parameters. Consequently, when the GC runs, it should find that the roots include a reference to the current object and not therefore mark it for collection.

So, in this case, the RegistryKey's instance method, DeleteSubKey, is being called and it shouldn't therefore be possible for the RegistryKey object to be GC'ed in the middle of this method call even though this object is not being used again in the rest of the program.

If this were possible and, if DeleteSubKey called another of RegistryKey's instance methods before returning, then that method call would fail because the object would no longer exist!
Vulpes12y ago
No, it doesn't look like it does.

I remember reading years ago that the /optimize compiler switch didn't do anything very profound and that blog post by Eric Lippert seems to bear that out.

The JIT will no doubt do more but, AFAIK, there's no way to control that. Given that it has to work in 'real time', there will also be a limit to what the JIT can do compared to, say, a C++ optimizing compiler.
Libor Theimer12y ago
It seems that optimize switch doesnt have any effect to GC - http://blogs.msdn.com/b/ericlippert/archive/2009/06/11/what-does-the-optimize-switch-do.aspx
Vulpes12y ago
You can compile your app with optimisations switched off ( vbc my app.vb /optimize- for a command line compile) but I don't know whether it will prevent what we've just been talking about or not. The documentation just says that it prevents code from being rearranged.

Yes, the behavior of the GC will be the same for all .NET applications, whatever language they were originally written in.

My own view is that you just have to live with all this if you write .NET applications and to take suitable precautions if you want to ensure that certain operations will always occur in the intended order.
Libor Theimer12y ago
is it possible to disable this type optimalization? I am not sure if it is helpful. I suppose that behavior of GC is the same for C# as wel as for VB.NET? Included example is in C#, but I am learning VB.NET.
Vulpes12y ago
I used to be an avid reader of Eric Lippert's blog though less so since he left Microsoft and I certainly don't remember reading this before.

There are certain things mentioned here which I already knew or thought I knew:

1. If an object was created during execution of a method and it was clear that it was no longer used, then (unless you were running in debug mode) the object could be marked for collection before that method ceased execution.

2. In a single threaded application, Microsoft had taken great care to ensure that things happen (or appear to happen) in the order the programmer expects but that this can't be assumed in a multi-threaded application.

However, I didn't know that:

1. That not only objects created within the method but objects passed in as parameters can be 'prematurely' garbage collected in this way including the 'this' reference which is implicitly passed as the first parameter to an instance method or constructor.

In the case of a constructor, this would be no great problem since, in addition to the constructor body itself, the JIT would only need to consider the method which called the constructor because the 'this' reference would not exist prior to that.

However, in the case of any other instance method, to be sure the object is no longer used, the JIT will have to consider not just the remaining code in the current method but the whole call stack of every currently running thread since the object was created!

2. Because the GC and finalization (of necessity) run on separate threads, even if the user code runs on a single thread it's still not safe to assume that things will happen in the order you expect.

This means that every application is effectively multi-threaded and great care needs to be taken if it's important that things only happen in a certain order.

If these conclusions are valid and Microsoft thinks that this is an acceptable situation then I'm not surprised that many C++ programmers still feel that the vagaries of garbage collection mean that .NET is just not suitable for 'mission critical' applications and that at least with their language the programmer is master of his/her own fate.

Of course, with stuff like this, you could run the application a thousand times without seeing any problem. If and when a problem does occur, it's going to be extremely difficult to debug unless you're aware of what can happen in .NET's 'garbage collected' world.
?????? ???????12y ago
Sorry, I'm a bit late. Just wanted to make things clearer.
Actually, it IS possible and perfectly legal for GC to 'free' an object even while its constructor (!!) is running. Mr. Lippert has written a nice (as always:)) blog post on the subject: http://ericlippert.com/2013/06/10/construction-destruction/
But in your case, as far as I can see there is NO chance for such a 'situation' since DeleteSubKey method uses a reference to hKey field of the object and no optimizer can change it;

Of course, I can not not be AbsolutelY sure that it cannot be GC'ed. The real dark magic is always out there. So the best way to check it out is to write a test and catch that exception) Haven't you tried it yet?
Libor Theimer12y ago
thank you
Vulpes12y ago
Suppose the example is correct and it is possible for the current object to be GC'ed whilst the DeleteSubKey method is executing.

Suppose also that the DeleteSubKey method were to call another instance method of the same class before returning (I know it's not doing that in the example but in practice it could do that).

Then the call to the other instance method would fail because the object no longer existed.

This is the point I was trying to make in the last paragraph of my previous post and would clearly be a serious bug in the GC subsystem.

I have the greatest respect for Adam Nathan and this particular book which was the standard work on interoperability in the early years of .NET. However, I think this example must either be wrong or there actually was a bug in the GC at the time which (hopefully) has now been addressed.
Libor Theimer12y ago
Your explanation sounds logical. attached example and its description is from the book. NET and COM: The Complete Interoperability Guide by Adam Nathan. this man has some relation to http://www.pinvoke.net/ and he is a serious in my opinion. so I didn't know if I can trust this crazy example.

But my english is not very good and I don't exactly understand to your last paragraph.

Thank You
LT