I don't think this hidden field would ever have to be implemented.
I think a safe and naive implementation would be to implement it as
overwriting the method table pointer with itself, with the write treated
as volatile, and a volatile read used to look up the finalize
entry in the method table when the finalizer is invoked.
But I think if the collector ever stops the mutator, it suffices to make
sure that the compiler keeps around the object pointer through the
System.reachable (or whatever) call. If the mutator is stopped before the
call, the object won't be finalized this cycle. If the mutator is stopped
after the call, the action of stopping the thread and communicating with
the finalizer will ensure visibility.
In terms of performance, this is a pure win, at least as far as I can see.
The down side is the addition of a relatively esoteric construct in support
of another one that is (or at least should be) already rarely used.
As far as the name is concerned, I'm not sure I like unmovableReference,
since the ordering constraints are really equivalent to those of a volatile
write, and this name suggests a read with more of a generic barrier, not
simply release semantics. doNotFinalizeYet() is OK, so long as we agree
that java.lang.ref is basically finalization.
Hans
> -----Original Message-----
> From: owner-javamemorymodel@cs.umd.edu
> [mailto:owner-javamemorymodel@cs.umd.edu]On Behalf Of Joseph Bowbeer
> Sent: Monday, November 24, 2003 2:26 PM
> To: javamemorymodel@cs.umd.edu
> Subject: Re: JavaMemoryModel: finalization review
>
>
> Bill Pugh writes:
>
> > The semantics would be as mentioned before (a volatile write to
> > a hidden field of the object that is read before finalization of the
> > object).
>
> Would this increase the size of all objects by 4 bytes? (If
> so, this seems
> like a lot of memory to invest in something that is so seldom used.)
>
>
> ----- Original Message -----
> From: "Bill Pugh" <pugh@cs.umd.edu>
> To: "Boehm, Hans" <hans_boehm@hp.com>; "'Sylvia Else'"
> <sylviae@optushome.com.au>; <javamemorymodel@cs.umd.edu>
> Sent: Monday, November 24, 2003 12:42 PM
> Subject: RE: JavaMemoryModel: finalization review
>
>
>
> >
> >
> >and the finalizer only needs to synchronize on impls. I'm perfectly
> >happy with
> >that. But it's clearly not backward compatible with existing VMs,
> >and hence would need
> >to be an addition to the current reachability rules, not a
> >replacement. (I suspect that
> >adding a method to Object is not really feasible, so you would
> >really have to say
> >something like System.reachable(this), but I'm not sure I understand
> >all the issues
> >there.)
>
>
> Of the syntax/api changes suggested on the list recently, I think
> this is the only one that might be doable at this late state, perhaps
> along with removing spurious wakeups from wait.
>
> I'm not sure I like reachable as a name, since it is so tightly tied
> to finalization. How about
> System.doNotFinalizeYet(Object o)
> The semantics would be as mentioned before (a volatile write to a
> hidden field of the object that is read before finalization of the
> object).
>
> 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:00:54 EDT