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
