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
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:54 EDT