File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Java in General and the fly likes Heap vs Stack aka object lifecycle? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "Heap vs Stack aka object lifecycle?" Watch "Heap vs Stack aka object lifecycle?" New topic
Author

Heap vs Stack aka object lifecycle?

Faisal syed
Ranch Hand

Joined: Mar 25, 2011
Posts: 35
Hi Friends,
I understand that objects stay on heap, and methods on stack.
However, Consider a local method



Can someone please explain me for how long this obj lives.
Once the method exits, will the obj disappear off the heap as well??

Thanks
Faisal
Jesper de Jong
Java Cowboy
Saloon Keeper

Joined: Aug 16, 2005
Posts: 14268
    
  21

There is no guarantee when the object will be cleaned up - it's up to the garbage collector to decide when exactly it is cleaned up.

If there are no references to an object anymore from any live threads, the object becomes eligible for garbage collection.

When the garbage collector cleans up an object, the memory on the heap that was used for the object is made free again.


Java Beginners FAQ - JavaRanch SCJP FAQ - The Java Tutorial - Java SE 8 API documentation
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 39396
    
  28
Unless it is something which comes up in an exam, that is a question you never need the answer to.
Faisal syed
Ranch Hand

Joined: Mar 25, 2011
Posts: 35
True. It was an interview question posed at me.
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Campbell Ritchie wrote:Unless it is something which comes up in an exam, that is a question you never need the answer to.


I disagree. I think it's valuable for a Java programmer to know the conditions under which an object is or is not reachable. Most of the time we don't need to think about it, but situations do arise where we need to think about whether an object might be sticking around in memory after it's no longer needed.

It is true that details beyond what constitutes reachability are not generally important.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 39396
    
  28
I didn’t mean you don’t have to know about reachability. I mean you don’t have to know exactly when an object is deleted from memory.
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Campbell Ritchie wrote:I didn’t mean you don’t have to know about reachability. I mean you don’t have to know exactly when an object is deleted from memory.


Oh, okay. Yes, I agree with that. Knowing when it can be deleted, important. Knowing when it will be deleted, not important. (And generally not possible anyway.)
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 39396
    
  28
You can find out when it is deleted by putting a print statement in its finalize() method, but that is crap programming if ever I saw it
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 3018
    
  10
Even with that, you don't find out when it actually is deleted. You just find out a time at which it had not yet been deleted, but was determined to be eligible for deletion. The finalizer must run before deletion, but there's no guarantee that deletion will immediately follow after the finalizer.

Also, the act of adding a finalizer to a class can affect how promptly its instances are deleted. any class with a finalizer is harder to delete, because the finalizer has the theoretical potential to do something which again makes the class accessible to live threads - even though prior to this, it wasn't, which was why it was scheduled for deletion in the first place. Reachability needs to be re-checked after the finalizer has run, before deletion can be performed. But if a class has no finalizer, that's not an issue - so deletion can be performed more promptly..
Steve Luke
Bartender

Joined: Jan 28, 2003
Posts: 4181
    
  21

Mike Simmons wrote:Even with that, you don't find out when it actually is deleted. You just find out a time at which it had not yet been deleted, but was determined to be eligible for deletion. ...


How about PhantomReferences in a ReferenceQueue? From Ethan Nicholas on Java.net:
PhantomReferences are enqueued only when the object is physically removed from memory, and the get() method always returns null specifically to prevent you from being able to "resurrect" an almost-dead object.

What good are PhantomReferences? I'm only aware of two serious cases for them: first, they allow you to determine exactly when an object was removed from memory. They are in fact the only way to determine that...

Second, PhantomReferences avoid a fundamental problem with finalization [as described by Mike]... Because PhantomReference cannot be used to resurrect an object, the object can be instantly cleaned up during the first garbage collection cycle


Is it true that PhantomReferences can be used to find out exactly when an object is collected (by listening to the ReferenceQueue)?


Steve
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 3018
    
  10
Steve Luke wrote:Is it true that PhantomReferences can be used to find out exactly when an object is collected (by listening to the ReferenceQueue)?

I don't know much about Phantom References really, but from the docs, I don't think so. It sounds like this may be the closest we can get to knowing this info, but it still seems to fall short of knowing "exactly", at least according to the docs. It seems that a PhantomReference is enqueued sometime after the object becomes phantom reachable - and then the object can't actually become unreachable until the PhantomReference is cleared. Or until the PhantomReference itself becomes unreachable. Once you hit clear(), that's as close as you can get to when the object is actually deleted. But there's still no guarantee it happens right away - or ever. Unless there's a guarantee somewhere that I've overlooked, which is always possible.
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18655
    
    8

This isn't my idea, I saw it somewhere on the web, but it might be possible to override the get() method to return the referent, rather than null:



I haven't tried this so I have no idea if it's possible or, if it is, what the consequences are.
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 3018
    
  10
I doubt it would mean anything. You can create a PhantomReference yourself using the constructor, and you can create a subclass of PhantomReference and instantiate it, sure. But that in itself doesn't tell you anything about the reachability of the referenced object. A PhantomReference is only meaningful if it's been created by the garbage collector, as a way of notifying interested parties that the given object is now phantom reachable. And the garbage collector isn't going to create a NaughtyPhantomReference, only a proper PhantomReference, which will continue to not expose the referent, instead returning null like it should.
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18655
    
    8

I haven't used PhantomReference either, but I have used SoftReference. The reference classes aren't created by the garbage collector, they are created by the application code. So it's the application which would be creating a subclass of PhantomReference and adding it to a ReferenceQueue.

And PhantomReference is absolutely useless on its own -- when you remove it from a ReferenceQueue, all it tells you is that some object is ready to be reclaimed by the garbage collector, but it doesn't tell you anything else. So subclassing would be mandatory, I think. Normally I think you'd just attach a command of some kind to the PhantomReference object and run that command when you get it back from the queue. Just like you would write a finalizer for the object. But like I said I haven't used them and I haven't even seen any tutorial about them, so that's just my best guess at what they are for.
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 3018
    
  10
Yeah, I'd used other references too, but for some reason I thought PhantomReference was different. Never mind; I see I was wrong. I agree, you do instantiate them yourself, not the JVM.

I do think there are a few ways you could still do it without subclasses - e.g. if there's only one PhantomReference in a given queue. Or if you maintain a Map<PhantomReference,Handler> that would allow you to activate a given Handler to call arbitrary code in response to a given object becoming phantom reachable. Still, simply subclassing PhantomReference seems a good way to do it too.

I do think that creating a NaughtyPhantomReference would probably prevent the associated object from ever becoming phantom reachable. So although you could create a NaughtyPhantomReference, you'd never pull one out of a ReferenceQueue, and so it would still never give you a reference to a phantom reachable object.
Steve Luke
Bartender

Joined: Jan 28, 2003
Posts: 4181
    
  21

I think that would prevent the referred Object from ever becoming phantom reachable since you have a strong reference to it, so the PhantomReference would never be queued. This doesn't happen with SoftReference and WeakReference because the referent stored in the java.lang.ref.Reference class is treated specially by the GC (according to the code).

Paul Clapham wrote:This isn't my idea, I saw it somewhere on the web, but it might be possible to override the get() method to return the referent, rather than null:



I haven't tried this so I have no idea if it's possible or, if it is, what the consequences are.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Heap vs Stack aka object lifecycle?