On 8/30/2014 10:35 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?=
<[email protected]>" wrote:
The problem is not only dereferencing those pointers (though depending
on how the GC works even this might be racy, i.e. the memory location
could have been reused already), but that a destructor/finalizer already
ran on the referenced object. It is thus potentially in an invalid
state. Even copying it is dangerous, because you're then creating a live
object from that invalid state which will itself be destroyed again at
some point. This might lead to double frees of depending manually
allocated objects, or potentially other problems. Then there's the
possibility to "resurrect" such an object by storing a reference to it
somewhere else during finalization.
Doing the scanning and finalization separately like this is _probably_
safe:
1. Marking phase as usual.
2. Select the objects that have a finalizer, and clear all references in
them that point to objects that are now unreachable. (This requires a
precise GC.)
3. Call the finalizers.
Not sure what to do about things that may or may not be references.
It's perfectly fine to not be able to guarantee the order of the
finalization, but we can guarantee that the values referenced by the
allocation being finalized are still allocated. It's up to the user to
understand that the finalizable object they are trying to reference in
their destructor may already have been finalized.
