Garbage collector and references

[Mohammad Javad Dousti]

Hi,
Please assume this little program:

class A{
int m;
}

class B{
public static void main(String[] args)
{
new A();
//do some other works
}}



So, does garbage collector delete A after newing it?

 

[Roedy Green]

So, does garbage collector delete A after newing it?

see http://mindprod.com/jgloss/garbagecollection.html
http://mindprod.com/jgloss/reference.html

 

[Lew]

Hi,
Please assume this little program:

class A{
int m;
}

class B{
public static void main(String[] args)
{
new A();
//do some other works
}}

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.

 

[Mohammad Javad Dousti]

Thanx Lew for your precise answer and spending your time for me.

 

[Eric Sosman]

[... 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?

 

[Joshua Cranmer]

[... 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?

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.

 

[Roedy Green]

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.

 

[Lew]

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.

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?