On Sat, 13 Oct 2007 13:15:10 -0700, Mohammad Javad Dousti
<javad.fan@gmail.com> wrote, quoted or indirectly quoted someone who
said :
>So, does garbage collector delete A after newing it?
see http://mindprod.com/jgloss/garbagecollection.html
http://mindprod.com/jgloss/reference.html

Signature
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com
> Hi,
> Please assume this little program:
[quoted text clipped - 11 lines]
>
> So, does garbage collector delete A after newing it?
Good question, because understanding garbage collection (GC) is important.
Optimization has an effect here, too.
The only generally accurate answer is, "It depends."
It is possible the optimizer might not even let the JVM instantiate an A,
which I'm going to call Foo because that is easier to read than a
single-letter class name.
In the event that the JVM does create an instance of Foo, there is no
requirement that GC ever reclaim its storage. That little bit of heap might
remain there for the rest of the application.
Or not.
Under certain circumstances it is conceivable that rather than GCing the
memory formerly occupied by an object, the optimizer will make the JVM reuse
it for a newly-created instance. For example:
for( int i = 0; i < LEN; ++i )
{
Foo foo = new Foo();
doSomething( foo );
}
Although each time around the loop 'foo' points to a new instance, not in any
way related to the last time(s) through the loop, the optimizer *might* decide
to re-use the storage for each new instance, thus saving a couple of clock
cycles for instantiation. GC would not be relevant in that situation until
after the loop finishes. (Assuming no finalize() override.)
If this does not happen, then old Foo instances will probably hang around for
a while. If the "young" generation fills up, the GC will want to get rid of
the storage used by those old instances, and will reclaim some or all of that
storage. Or it might not need to, and the storage will remain unclaimed until
the program terminates.
Objects with a short lifetime, like our 'foo' inside a tight loop, will tend
to get cleaned up more quickly.
In a meaningful way the object is "deleted" right at the moment that nothing
inside the program refers to it any more, directly or indirectly. That is
really all the "deleted" you need. "Garbage collected" is a different issue,
involving running finalizers and reclaiming memory, and no guarantees that
it'll even happen for any given object.

Signature
Lew
Mohammad Javad Dousti - 13 Oct 2007 22:22 GMT
Thanx Lew for your precise answer and spending your time for me.
Eric Sosman - 13 Oct 2007 23:06 GMT
> [... regarding `new A();' with no reference saved anywhere ...]
>
> It is possible the optimizer might not even let the JVM instantiate
> an A, [...]
Isn't the construction of an A instance required by the
definition of Java? Is there a language lawyer out there
who can elucidate?

Signature
Eric Sosman
esosman@ieee-dot-org.invalid
Joshua Cranmer - 14 Oct 2007 00:32 GMT
>> [... regarding `new A();' with no reference saved anywhere ...]
>>
[quoted text clipped - 4 lines]
> definition of Java? Is there a language lawyer out there
> who can elucidate?
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.

Signature
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth
Roedy Green - 14 Oct 2007 11:42 GMT
On Sat, 13 Oct 2007 18:06:16 -0400, Eric Sosman
<esosman@ieee-dot-org.invalid> wrote, quoted or indirectly quoted
someone who said :
> Isn't the construction of an A instance required by the
>definition of Java?
it would have to be. The constructor could have all sorts of side
effects. The only time I'd think it could be discarded if the
optimiser to prove to itself there were no side effects.

Signature
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com
Lew - 14 Oct 2007 18:39 GMT
> On Sat, 13 Oct 2007 18:06:16 -0400, Eric Sosman
> <esosman@ieee-dot-org.invalid> wrote, quoted or indirectly quoted
[quoted text clipped - 6 lines]
> effects. The only time I'd think it could be discarded if the
> optimiser to prove to itself there were no side effects.
Exactly. The optimizer can inline certain things, for example an immutable
object's member accesses. Under the right run-time circumstances, the
optimizer can eliminate an object creation altogether.
Of course it won't do that if to do so would change the semantics of the
program. Isn't it a given that the optimizer won't make that mistake?

Signature
Lew