On Thu, 10 Apr 2003, Richard Jones wrote:
> That model is easy to explain. It may also be easy to explain a synchronised
> fix. The key point is that if we want to reduce the volume of broken code that
> it written, it's not sufficient simply to declare code as broken or to
> construct correct memory model. The result has to be a model that can be easily
> assimilated by programmers. Otherwise they will simply continue to write broken
I really have to agree here (and with David Holmes' & other prior posts).
The intent (if not actual specification) of finalizers that i understood
when introduced to java is that they are run when the object is definitely
not accessible in any way. I think that most programmers would/will
insist that a virtual method call on an object makes that object
conceptually live---certainly it shouldn't be the case that an object
reference can be declared unreachable and pulled away from under its feet
if there's any potential observable difference (eg finalizers touching the
same fields or objects).
GC is after all supposed to help the programmer. Making the lifetime of a
variable hard(er) to predict does not do this---as we're seeing,
optimizations that may alter lifetimes of variables require defensive
programming in case premature GC causes premature finalization; why make
programming harder? Potential optimization benefits do not transparently
seem better when compared to the cost and complexity of having the
programmer (correctly) insert synchronization all over, with the compiler
expected to optimize away most of that.
BTW: In any case using (requiring) the synchronization syntax _purely_ to
extend the lifetime of an object seems counter-intuitive to me. It
exploits a subtle side-effect of the known interpretation (locking) of
that syntax---in that sense at least keepAlive() has an obvious
correspondence to the intended functionality.
-- ttfn, clark email@example.com
------------------------------- JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:44 EDT