Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Objects that can't be garbage collected?

Reply
Thread Tools

Objects that can't be garbage collected?

 
 
Daniel
Guest
Posts: n/a
 
      10-22-2007
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?

 
Reply With Quote
 
 
 
 
Daniel Pitts
Guest
Posts: n/a
 
      10-22-2007
Daniel wrote:
> 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.

--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
 
Reply With Quote
 
 
 
 
Jean-Baptiste Nizet
Guest
Posts: n/a
 
      10-22-2007
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.

 
Reply With Quote
 
Daniel Pitts
Guest
Posts: n/a
 
      10-22-2007
Jean-Baptiste Nizet wrote:
> 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.

--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
 
Reply With Quote
 
Christopher Benson-Manica
Guest
Posts: n/a
 
      10-22-2007
[comp.lang.java.programmer] Daniel Pitts <(E-Mail Removed)> wrote:

> 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?"

--
C. Benson Manica | I appreciate all corrections, polite or otherwise.
cbmanica(at)gmail.com |
----------------------| I do not currently read any posts posted through
sdf.lonestar.org | Google groups, due to rampant unchecked spam.
 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      10-22-2007
Daniel Pitts wrote:
>> Big hint: Don't point out when the interviewer makes a big mistake.


Christopher Benson-Manica wrote:
> 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.

--
Lew
 
Reply With Quote
 
Mark Space
Guest
Posts: n/a
 
      10-22-2007
Daniel Pitts wrote:

> 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.)
 
Reply With Quote
 
Patricia Shanahan
Guest
Posts: n/a
 
      10-22-2007
Mark Space wrote:
> Daniel Pitts wrote:
>
>> 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.)


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
 
Reply With Quote
 
Mark Space
Guest
Posts: n/a
 
      10-22-2007
Patricia Shanahan wrote:

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


 
Reply With Quote
 
Stefan Ram
Guest
Posts: n/a
 
      10-22-2007
Mark Space <(E-Mail Removed)> writes:
>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?

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
problem in running a basic code in python 3.3.0 that includes HTML file Satabdi Mukherjee Python 1 04-04-2013 07:48 PM
creating garbage collectable objects (caching objects) News123 Python 7 06-29-2009 04:12 PM
class objects, method objects, function objects 7stud Python 11 03-20-2007 06:05 PM
Templates - Garbage In Garbage Not Out ramiro_b@yahoo.com C++ 1 07-25-2005 04:48 PM
Can objects with active threads be garbage collected? Mark McKay Java 5 10-03-2003 03:33 AM



Advertisments