Re: Garbage collector and references

Eric Sosman wrote:


Starting with the Java VM spec, in the description of the instructions:

new [ description of the bytecode instruction ]
[ ... ]
Memory for a new instance of that class is allocated from the
garbage-collected heap, and the instance variables of the new object are
initialized to their default initial values (?2.5.1). The objectref, a
reference to the instance, is pushed onto the operand stack.

JLS 3 ?15.9.4 Run-time Evaluation of Class Instance Creation Expressions

[ ... ]
Next, space is allocated for the new class instance. If there is
insufficient space to allocate the object, evaluation of the class
instance creation expression completes abruptly by throwing an
OutOfMemoryError (?15.9.6).

The new object contains new instances of all the fields declared in the
specified class type and all its superclasses. As each new field
instance is created, it is initialized to its default value (?4.12.5).
[ ... ]
The value of a class instance creation expression is a reference to the
newly created object of the specified class. Every time the expression
is evaluated, a fresh object is created.

The introduction implies that implementations do not need to conform to
the standard as long as they appear to do so (ISO C/C++ explicitly has a
clause stating this; I haven't studied the JVM spec or the JLS in
sufficient detail, but I presume a similar clause applies).

My interpretation is that the destruction/reinstantiation can be
optimized away under the following circumstances:
1. The fields are at their default values (or reset to them).
2. There is no effect of the constructor (i.e., the constructor is the
default constructor through the hierarchy).
3. There is no effect of the finalize method.

Under those conditions, simply not destroying and reinitializing the
object would have no observable difference from doing so.
--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth