An idea to avoid a narrow class of bugs

[Jonathan M Davis]

On Monday, June 25, 2012 15:22:03 Alex Rønne Petersen wrote:
> > To me, it is a GC implementation issue. You should be able to allocate
> > in destructors.
> 
> Yes, I don't understand why on earth this limitation is in place. There
> is no (good) technical reason it should be there.

I believe that the main problem is that there's no guarantee that anything 
allocated on the GC heap will actually still exist when you the finalizer is 
run (since the order of destruction/finalization is undefined and in order to 
break circular references, the finalizer of a class could be run after some of 
its members' finalizers have been run), making it unsafe to access any stuff 
from the GC heap inside of the finalizer. But why that would prevent you from 
allocating inside of the finalizer, I don't know, since that would be newly 
allocated memory rather than memory that might have already been released as 
is the case if you reference member variables which are on the heap - though I 
don't know that it's really much of a restriction to not be able to allocate 
within the finilazire when allocating something on the GC heap without 
accessing anything else on the GC within the finalizer is unlikely to be useful 
very often (maybe it would be useful when creating an array or string to pass 
to a C function, but beyond that, I suspect that the fact that you can't 
access pre-existing stuff on the GC heap already prevents whatever you'd be 
trying to do in almost all cases).

- Jonathan MDavis