Objects that can't be garbage collected?

[Daniel]

I got a weird question in a phone interview the other day that I'm not
sure what to make of.

The question was "What object(s) cannot be garbage collected?" I asked
for a little clarification, and he said "What objects, if collected,
would cause problems [in the JVM]?"

Hmmmm... still not sure if 1) I accurately understood what he was
asking 2) It's a perfectly good question that I don't know the answer
to, or 3) it was a trick question

If it's #2, hopefully someone will fill me in.

My first thoughts were that this must be a theoretical question, b/c
if there were such a situation where an object is collected before
it's safe to do so, then it would be a pretty big bug in the JVM
implementation.

Going for the theoretical angle, my thoughts were that something like
a ClassLoader object could be the answer. Let's say that somehow, I
managed to erase the reference from Foo to the FooClassLoader that
loaded it , and that it is collected before an instance of Foo calls a
method that uses an instance of Foo2 (assume that Foo and Foo2 are
from a library that only FooClassLoader has access to.) We'd have a
something like a ClassNotFoundException from the bootstrap CL,
correct? As far as the "realisticalness" of the situation, it seems
like the ability to manipulate a class's ClassLoader field would
violate the security model. Then again, if the reference in Foo to
its class loader is simply a regular private member, then Foo could
set the reference to null in its constructor or some other point,
correct?

Am I missing something obvious, or is this a weird question?

 

[Daniel Pitts]

I got a weird question in a phone interview the other day that I'm not
sure what to make of.

The question was "What object(s) cannot be garbage collected?" I asked
for a little clarification, and he said "What objects, if collected,
would cause problems [in the JVM]?"

Hmmmm... still not sure if 1) I accurately understood what he was
asking 2) It's a perfectly good question that I don't know the answer
to, or 3) it was a trick question

If it's #2, hopefully someone will fill me in.

My first thoughts were that this must be a theoretical question, b/c
if there were such a situation where an object is collected before
it's safe to do so, then it would be a pretty big bug in the JVM
implementation.

Going for the theoretical angle, my thoughts were that something like
a ClassLoader object could be the answer. Let's say that somehow, I
managed to erase the reference from Foo to the FooClassLoader that
loaded it , and that it is collected before an instance of Foo calls a
method that uses an instance of Foo2 (assume that Foo and Foo2 are
from a library that only FooClassLoader has access to.) We'd have a
something like a ClassNotFoundException from the bootstrap CL,
correct? As far as the "realisticalness" of the situation, it seems
like the ability to manipulate a class's ClassLoader field would
violate the security model. Then again, if the reference in Foo to
its class loader is simply a regular private member, then Foo could
set the reference to null in its constructor or some other point,
correct?

Am I missing something obvious, or is this a weird question?

A class loader may be reclaimed, along with any class that is within it,
following the same logic as any other object. JLS 12.7
<http://java.sun.com/docs/books/jls/third_edition/html/execution.html#12.7>

The only thing that I can think of is the system class loader and system
classes. Alternatively, objects that still have hard references to
them, although this kind of goes without saying.

 

[Jean-Baptiste Nizet]

It is a weird question, IMO.
Maybe he wanted you to say that you could cause problems to the GC/JVM
if you did something bad in the finalize method. For example, storing
a new reference of the object being finalized in a reachable
collection or something like that.

JB.

 

[Daniel Pitts]

It is a weird question, IMO.
Maybe he wanted you to say that you could cause problems to the GC/JVM
if you did something bad in the finalize method. For example, storing
a new reference of the object being finalized in a reachable
collection or something like that.

JB.

I believe that is "valid", and would only delay the collection. The
finalizer wouldn't be executed again either.

Still, I agree, strange question. Perhaps showing a lack of
understanding by the part of the interviewer. Big hint: Don't point out
when the interviewer makes a big mistake.

 

[Christopher Benson-Manica]

Big hint: Don't point out when the interviewer makes a big mistake.

Although such an occurrence should make one wonder, "If they can't get
this right, what is the code here like?"

 

[Lew]

Although such an occurrence should make one wonder, "If they can't get
this right, what is the code here like?"

Leading to, "Do point out to the interviewer that they have their head up
their [sleeve]," and accept not getting the job offer.

And thank your lucky stars that you didn't.

 

[Mark Space]

I believe that is "valid", and would only delay the collection. The
finalizer wouldn't be executed again either.

Interesting...

Still, I agree, strange question. Perhaps showing a lack of
understanding by the part of the interviewer. Big hint: Don't point out
when the interviewer makes a big mistake.

I was thinking bootstrap class loader, the run time (java.*, javax.*)
classes like String which are probably in use by the JVM all the time,
class objects themselves (if still in use), interred strings, threads in
use, the AWT Event thread, and "obvious" classes which are still
referenced by other classes (e.g., an event handler class still
referenced by a JComponent, even if the component has been hidden, or
maybe even disposed -- imagine an JComponent which is disposed but one
of it's event listeners is still being executed; not nice.)

 

[Patricia Shanahan]

I was thinking bootstrap class loader, the run time (java.*, javax.*)
classes like String which are probably in use by the JVM all the time,
class objects themselves (if still in use), interred strings, threads in
use, the AWT Event thread, and "obvious" classes which are still
referenced by other classes (e.g., an event handler class still
referenced by a JComponent, even if the component has been hidden, or
maybe even disposed -- imagine an JComponent which is disposed but one
of it's event listeners is still being executed; not nice.)

Isn't it possible that the interviewer was looking for a much more basic
answer? My first response would have been "Objects that are reachable by
any potential continuing computation in any live thread.", possibly with
some commentary on the fact that the default class loader is always
reachable...

Patricia

 

[Mark Space]

Isn't it possible that the interviewer was looking for a much more basic
answer? My first response would have been "Objects that are reachable by

Yes, and I should have said the same, because I was thinking that this
should be the first answer. Interviewers are testing more than just
technical knowledge. They want to know that you can communicate. They
also want to know that you can keep calm under pressure. I've known
interviewers would throw screwy questions into an interview just to test
the candidate's response. It's a *personality* test question.

I guess one could venture "Objects that are still in use, such as by a
reference." Then add "Is that along the lines you are looking for?
Should I elaborate further?" Pretend the interview is on your team and
the two of you are trying to solve some problem.

 

[Stefan Ram]

I guess one could venture "Objects that are still in use, such as by a
reference." Then add "Is that along the lines you are looking for?

Yesterday I had to think about something inspiring this
exercise:

public class A
{ private O o = new O();
public void run(){ o.something( this ); }
public void unlink(){ o = null; /* can o be reclaimed here? */ }}

Given the code of the above class A (that can't be changed),
one might be inclined to assume that directly after
»o = null;«, the object »o« can always be safely reclaimed.

This is not about reflection tricks to get a copy of the
private field »o« (these are not allowed here). Since
there is no »getter« for »o«, the reference »o« is kept quite
confidentially within the class »A«.

Still, there is at least one situation, where »o« should not
be reclaimed directly after »o = null;«. What would be such a
situation?

 

[Patricia Shanahan]

Yesterday I had to think about something inspiring this
exercise:

public class A
{ private O o = new O();
public void run(){ o.something( this ); }
public void unlink(){ o = null; /* can o be reclaimed here? */ }}

Given the code of the above class A (that can't be changed),
one might be inclined to assume that directly after
»o = null;«, the object »o« can always be safely reclaimed.

This is not about reflection tricks to get a copy of the
private field »o« (these are not allowed here). Since
there is no »getter« for »o«, the reference »o« is kept quite
confidentially within the class »A«.

Still, there is at least one situation, where »o« should not
be reclaimed directly after »o = null;«. What would be such a
situation?

Has run() been called?

Even if it has finished running, o.something could have stored a
reference to the o object that is still accessible. Moreover, run()
could have been called in another thread, in which case o.something
could be running.

If A were Runnable its run() could even be the base method of another
thread.

Patricia

 

[Stefan Ram]

Has run() been called?

This is possible.

Even if it has finished running, o.something could have stored a
reference to the o object that is still accessible. Moreover, run()
could have been called in another thread, in which case o.something
could be running.

Yes, this seems to be correct.

But there is still another situation, when o can not
be reclaimed, even given that:

- There are no threads created (in addition to the usual
main thread)

- »o« does not store a reference to itself anywhere
(i.e., The declaration of the class »O« does not
contain »this« or any expression with the value
of »this«, and it does not contain code to transfer
a reference to »this« to any other party.)

 

[Patricia Shanahan]

This is possible.


Yes, this seems to be correct.

But there is still another situation, when o can not
be reclaimed, even given that:

- There are no threads created (in addition to the usual
main thread)

- »o« does not store a reference to itself anywhere
(i.e., The declaration of the class »O« does not
contain »this« or any expression with the value
of »this«, and it does not contain code to transfer
a reference to »this« to any other party.)

Can I also assume that it does not create a self-reference implicitly,
by creating an inner class object that is still reachable?

Patricia

 

[Stefan Ram]

Can I also assume that it does not create a self-reference implicitly,
by creating an inner class object that is still reachable?

It does not create a self-reference in this way.
There is no creation of an inner class involved.

(I will post the situation I think of not earlier than as of
2007-10-23T12:00:00+02:00, unless someone else comes up with it.)

 

[Daniel]

Isn't it possible that the interviewer was looking for a much more basic
answer? My first response would have been "Objects that are reachable by
any potential continuing computation in any live thread.", possibly with
some commentary on the fact that the default class loader is always
reachable...

Patricia- Hide quoted text -

- Show quoted text -

In retrospect, I think that's what he had to be after. Thanks for the
input and advice.

 

[Daniel Pitts]

It does not create a self-reference in this way.
There is no creation of an inner class involved.

(I will post the situation I think of not earlier than as of
2007-10-23T12:00:00+02:00, unless someone else comes up with it.)

While I'm sure its not what you're considering, a subclass of A could
override unlink().
The o instance isn't reachable from the stack, so I think it *can* be
reclaimed there, unless something special happens in the O constructor
or the o.something...
oh...
Hehe.
public class O {public void something(A a) { a.unlink(); }}

 

[Stefan Ram]

public class O {public void something(A a) { a.unlink(); }}

That indeed was the situation I was thinking about.

So the Reclaimer needs to look at the call stack to find all
active methods. For every active method it needs to find the
object of that method and treating it as live.

 

[microsoft_geek]

Dear Daniel
I have very small experince in this java field and i think the answer
of "What object(s) cannot be garbage collected?" is "The objects which
are reference of serialized classes cannot be garbage collected".
I came to know about this while i was on a training for core Java by a
Senior Java Developer from NIIT Ltd.
Explanation: As we all know Java don't have Destructors like in C++,
it uses garbage collector to destroy the objects and all other
resources which are not being used for a long time. But if we want to
have a object that cannot be garbage collected we have to make it
serialize with proper serial version id like Business Logic.

I think it will solve your query as far as my knowledge is concern.

Regards,
Aurobindo

 

[Lew]

That indeed was the situation I was thinking about.

So the Reclaimer needs to look at the call stack to find all
active methods. For every active method it needs to find the
object of that method and treating it as live.

Great example.

In addition, it points up some of the danger of circular dependencies.

 

[Lew]

public class O {public void something(A a) { a.unlink(); }}

Isn't this just a special case of there still being a live reference to the
member 'o'?