Jerry Schwarz wrote:
> Because that is the implication of what the JLS says about it.
>
> "Optimizing transformations of a program can be designed
> that reduce the number of objects that are reachable to be
> less than those which would naively be considered reachable".
I don't see the implication you mention. The fact that the JLS
recognises that optimisations might affect objects that "would be
naively considered reachable" doesn't mean that the compiler/optimiser
has free rein and can be blind to finalizers or the use of reference
queues. I don't consider many of the situations being discussed to be
"naive".
My view is that there is a very simple and clear logical programming
model in which the lifetime of references is established by the
actions of the program and the scopes in which those references exist.
In that model there is always a reference to 'this' available when a
method is executing; parameter references live until the method
completes; and reachability is determined by the current state of
threads and the current object graph - not on what a thread may or may
not do in the future.
An optimising compiler is free to break that logical model provided it
is not observable within the program. When finalizers exist or
reference queues are used, then that is not the case. Therefore, in my
view, the optimisations are not valid in those contexts.
Now correct use of finalization and reference queues requires
synchronization, so it may well be that by fixing this for the
synchronized case we can deal implicitly with the finalization case. I
realise that the compiler does not want to be doing "has finalizer"
tests on the code it is optimising.
I do not want to see anything like System.keepAlive(o). I'd rather see
an empty synchronized block and be able to explain everything in terms
of synchronization.
David Holmes
-------------------------------
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