• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Heap vs Stack aka object lifecycle?

 
Faisal syed
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 15448
42
Android IntelliJ IDE Java Scala Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Campbell Ritchie
Sheriff
Pie
Posts: 49827
69
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Unless it is something which comes up in an exam, that is a question you never need the answer to.
 
Faisal syed
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
True. It was an interview question posed at me.
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 49827
69
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 49827
69
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 3090
14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 4181
22
IntelliJ IDE Java Python
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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)?
 
Mike Simmons
Ranch Hand
Posts: 3090
14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Sheriff
Posts: 21322
32
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 3090
14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Sheriff
Posts: 21322
32
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 3090
14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 4181
22
IntelliJ IDE Java Python
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic