Lifetime of a local reference

[Marko Rauhamaa]

Alan Bawden <alan at csail.mit.edu>:

> Gregory Ewing <greg.ewing at canterbury.ac.nz> writes:
>
>> Alan Bawden wrote:
>> > the Java Language
>> > Specification contains the following language:
>> >    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.  For example, a Java compiler
>> >    or code generator may choose to set a variable or parameter that
>> >    will no longer be used to null to cause the storage for such an
>> >    object to be potentially reclaimable sooner.
>> 
>> However, it only makes sense to do that if the compiler can be
>> sure that reclaiming the object can't possibly have any side
>> effects. That's certainly not true of things like file objects
>> that reference resources outside of the program. I'd be pretty
>> upset if a Java implementation prematurely closed my files on
>> the basis of this clause.
>
> The Java compiler has no way to know whether a variable references an
> object with a finalize() method that has side effects, so that quote
> from the Specification licenses a Java implementation to do exactly
> the thing you say will make you upset.

And that's not only theoretical. Hotspot (as well as gcc on the C side)
has been very aggressive in taking liberties awarded by the standards.

What's trickier is that Hotspot's JIT optimizations kick in only when a
code snippet is executed numerous times. So often these effects don't
come up during functional testing but may make their way to production.


Marko