Bill,
Could you outline how this is justified in terms of the memory model and
proposed GC rules?
At the moment I have a vague feeling that the writes that the GC sees and
the writes that the memory model deals with are not the same sort of write,
in that the implementation is not obliged to perform any particular write,
either in any particular order, or indeed at all, provided that the outcome
is what the model requires. The GC on the other hand appears to be talking
about real writes into real objects.
Jerry has suggested that the optimiser might eliminate v = o. I'd go
further, and suggest that the optimiser could then eliminate the write v =
null, provided that the required happens-before relationships are maintained.
Sylvia.
At 03:02 PM 21/04/2004 -0400, Bill Pugh wrote:
>OK, here is a class that implements keepAlive:
>
>public class FinalizerHelp {
> static volatile Object v;
> public static void keepAlive(Object o) {
> v = o;
> v = null;
> }
> public static void getReadyToFinalize() {
> Object o = v;
> }
>}
>
>The semantics we provided to ensure that finalizer guardians would work
>will also ensure that an object is still reachable if we are going to
>write a reference to that object into a global variable.
>
>Because the write is a volatile write, preceding memory accesses can't
>be reordered with the call to keepAlive.
>
>The one point of ugliness here is that each finalizer should call
>FinalizerHelp.getReadyToFinalize().
>
>Bill
>
>-------------------------------
>JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:01:06 EDT