 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / October 2007Objects that can't be garbage collected?
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? > I got a weird question in a phone interview the other day that I'm not > sure what to make of. [quoted text clipped - 29 lines] > > 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.  SignatureDaniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/> 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. > It is a weird question, IMO. > Maybe he wanted you to say that you could cause problems to the GC/JVM [quoted text clipped - 3 lines] > > 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. SignatureDaniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/> > 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?" SignatureC. 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. 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?" 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. SignatureLew > 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.) >> I believe that is "valid", and would only delay the collection. The >> finalizer wouldn't be executed again either. [quoted text clipped - 13 lines] > 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 > 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. >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? >> 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? [quoted text clipped - 19 lines] > 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 >>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.) >>> public class A >>> { private O o = new O(); [quoted text clipped - 22 lines] > 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 >>>>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.) > >>>>public class A > >>>>{ private O o = new O(); [quoted text clipped - 8 lines] > (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(); }} >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. >> public class O {public void something(A a) { a.unlink(); }} > [quoted text clipped - 3 lines] > 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. SignatureLew >>> public class O {public void something(A a) { a.unlink(); }} >> [quoted text clipped - 7 lines] > > In addition, it points up some of the danger of circular dependencies. Indeed. Anybody know if modern garbage collectors use reference counts to aid in non-circular references? That seems like a frequent enough case that it might improve performance. It would even help in the above example. SignatureDaniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/> 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? */ }} > 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'? SignatureLew > >> I believe that is "valid", and would only delay the collection. The > >> finalizer wouldn't be executed again either. [quoted text clipped - 23 lines] > > - Show quoted text - In retrospect, I think that's what he had to be after. Thanks for the input and advice. 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 >If it's #2, hopefully someone will fill me in. Those sorts of questions are a sign you should look elsewhere for employment. This is not a practical question. It is just time wasting hazing. To learn a bit about gc, see http://mindprod.com/jgloss/garbagecollection.html http://mindprod.com/jgloss/packratting.html SignatureRoedy Green Canadian Mind Products The Java Glossary http://mindprod.com Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.