Objects that can't be garbage collected?

Discussion in 'Java' started by Daniel, Oct 22, 2007.

  1. Daniel

    Daniel Guest

    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, Oct 22, 2007
    #1
    1. Advertisements

  2. Daniel

    Daniel Pitts Guest

    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/>
     
    Daniel Pitts, Oct 22, 2007
    #2
    1. Advertisements

  3. 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.
     
    Jean-Baptiste Nizet, Oct 22, 2007
    #3
  4. Daniel

    Daniel Pitts Guest

    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/>
     
    Daniel Pitts, Oct 22, 2007
    #4
  5. [comp.lang.java.programmer] Daniel Pitts <> 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.
     
    Christopher Benson-Manica, Oct 22, 2007
    #5
  6. Daniel

    Lew Guest

    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
     
    Lew, Oct 22, 2007
    #6
  7. Daniel

    Mark Space Guest

    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.)
     
    Mark Space, Oct 22, 2007
    #7
  8. 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
     
    Patricia Shanahan, Oct 22, 2007
    #8
  9. Daniel

    Mark Space Guest

    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.
     
    Mark Space, Oct 22, 2007
    #9
  10. Daniel

    Stefan Ram Guest

    Mark Space <> 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?
     
    Stefan Ram, Oct 22, 2007
    #10
  11. Stefan Ram wrote:
    > Mark Space <> 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?
    >


    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
     
    Patricia Shanahan, Oct 23, 2007
    #11
  12. Daniel

    Stefan Ram Guest

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

    >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.)
     
    Stefan Ram, Oct 23, 2007
    #12
  13. Stefan Ram wrote:
    > Patricia Shanahan <> writes:
    >>> public class A
    >>> { private O o = new O();
    >>> public void run(){ o.something( this ); }
    >>> public void unlink(){ o = null; /* can o be reclaimed here? */ }}

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


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

    Patricia
     
    Patricia Shanahan, Oct 23, 2007
    #13
  14. Daniel

    Stefan Ram Guest

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

    >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.)
     
    Stefan Ram, Oct 23, 2007
    #14
  15. Daniel

    Daniel Guest

    On Oct 22, 12:37 pm, Patricia Shanahan <> wrote:
    > 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- 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, Oct 23, 2007
    #15
  16. Daniel

    Daniel Pitts Guest

    On Oct 22, 4:56 pm, -berlin.de (Stefan Ram) wrote:
    > Patricia Shanahan <> writes:
    > >>>>public class A
    > >>>>{ private O o = new O();
    > >>>> public void run(){ o.something( this ); }
    > >>>> public void unlink(){ o = null; /* can o be reclaimed here? */ }}

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


    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(); }}
     
    Daniel Pitts, Oct 23, 2007
    #16
  17. Daniel

    Stefan Ram Guest

    Daniel Pitts <> writes:
    >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.
     
    Stefan Ram, Oct 23, 2007
    #17
  18. 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
     
    microsoft_geek, Oct 23, 2007
    #18
  19. Daniel

    Lew Guest

    Stefan Ram wrote:
    > Daniel Pitts <> writes:
    >> 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.


    Great example.

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

    --
    Lew
     
    Lew, Oct 23, 2007
    #19
  20. Daniel

    Lew Guest

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


    Daniel Pitts wrote:
    > 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'?

    --
    Lew
     
    Lew, Oct 23, 2007
    #20
    1. Advertisements

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. =?Utf-8?B?Sg==?=

    When are static members garbage collected?

    =?Utf-8?B?Sg==?=, Feb 25, 2004, in forum: ASP .Net
    Replies:
    1
    Views:
    382
    bruce barker
    Feb 25, 2004
  2. Cheng Thao
    Replies:
    0
    Views:
    437
    Cheng Thao
    Aug 6, 2003
  3. Mark McKay
    Replies:
    5
    Views:
    940
    xarax
    Oct 3, 2003
  4. Scott Robinson

    Socket being garbage collected too early

    Scott Robinson, Dec 16, 2004, in forum: Python
    Replies:
    4
    Views:
    456
    Scott Robinson
    Dec 18, 2004
  5. Mike Harrison
    Replies:
    1
    Views:
    151
    Thomas 'PointedEars' Lahn
    Mar 14, 2010
Loading...

Share This Page