Alan Bawden <a...@csail.mit.edu>: > Gregory Ewing <greg.ew...@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 -- https://mail.python.org/mailman/listinfo/python-list