At 04:22 PM 20/11/2003 -0800, Boehm, Hans wrote:
>I spent a little bit of time revising an example of finalization
>use in Java I had constructed earlier. I think is fairly representative
>of a reasonable class of finalization uses.
Hans' example illustrates what a heavyweight approach to solving the
underlying problem using synchronization is.
Essentially, the problem to be solved is that there is a form of
reachability from the running thread to the external resource that the GC
cannot see. The fix is to ensure that reachability of the external resource
implies reachability of the wrapper class, which the GC can see.
Using synchronization in this way is not merely counter intuitive, but
imposes a synchronization cost (and associated serialization) on every
access to the external resource, even when this may not otherwise be required.
Implementors have objected to the idea of ensuring that a thread can reach
its this object until it returns on the grounds that it prevents some
optimisations, such as tail call elimination.
How about we extend the language to allow the (admittedly overloaded)
native word to be used on a field. The semantics would be that the
containing object will not be finalized while a method that references the
field is in progress (from the programmer's perspective). This would limit
the optimisations, but only for these methods.
According the VM spec, setting another bit in the field attributes can be
done without breaking existing VMs (though a program that needs it is
probably broken on such VMs anyway).
Sylvia.
-------------------------------
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