Lifetime of a local reference
marko at pacujo.net
Thu Feb 28 03:49:01 EST 2019
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.
More information about the Python-list