David Bacon says:
> how do you propose to implement this? since we never know when an
> object will become garbage, and since it can be GC'd and have its
> finalizers run at any time after it does become garbage, you're either
> architecting in a global synchronization before any finalizer can be
> run, or else requiring that all writes to objects with finalizers be
> treated as though they are volatile.
>
> the latter seems unacceptable from a performance point of view. the
> former isn't a problem when you are doing stop-the-world GC, but would
> be onerous for incremental GC's.
I certainly agree with the general point that we should think hard before
constraining future implementations unduly. On the specific point,
however, I'm unable to think of a concurrent/incremental GC style for
which this constraint would be much of a hardship. For example, the
Train algorithm is usually considered incremental, but is usually done
in a stop-the-world style. But it's quite possible this reflects a
paucity of imagination on my part. Can you propose one (respecting,
of course, intellectual property constraints?)
("I can neither confirm nor deny" will be interpreted appropriately :-)
Dave
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:24 EDT