aspose file tools
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Who decides when to reclaim objects? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of Head First Android this week in the Android forum!
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "Who decides when to reclaim objects?" Watch "Who decides when to reclaim objects?" New topic

Who decides when to reclaim objects?

Marlene Miller
Ranch Hand

Joined: Mar 05, 2003
Posts: 1391
I am going to ask my question in several different ways.
Where does the decision occur whether to reclaim memory, within the garbage collector, or within the JVM but outside of the garbage collector?
Is the garbage collector passive?
Does the JVM decide it is time to reclaim storage and therefore it calls the gc or does the gc, having been called by the JVM, decide whether or not it is time to reclaim storage?
Suppose you decide to change the gc algorithm in your JVM. So you replace the gc code. Have you changed *when* gc occurs or only *how* it occurs?
Bert Bates

Joined: Oct 14, 2002
Posts: 8898
Marlene -
There is nothing in the Java specification about how garbage collection is implemented. So no particular behavior is guaranteed, except the behavior for handling the finalize() method and how the JVM determines whether an object is reachable. 12.6.1 JLS.
After that it all depends on the implementation of the virtual machine. If you want to learn about Java Hotspot here is a link,

But no implementation specifics are on the exam.
What is on the exam is what the programmer is responsible for and can control, 'making an object eligible for garbage collection'. The key in the exam is to understand whether an object is reachable by a live thread, and how the programmer can make an object unreachable. Finally, you have to know what's true about the finalize() method.
For finalize - if the GC decides to collect an object, the finalize() method will be invoked once, before the object is reclaimed. If however, the object becomes reachable again and then unreachable again, the GC won't call finalize() again for that object. An object can become 're-reachable', if the finalize() method passes a reference to the object to a different live object. That reference passing would render the previously doomed object, no longer GC eligible.
Also, remember, there is NO guarantee that a particular object will EVER be reclaimed, therefore there is no guarantee that any finalize() method will ever be invoked.
[ April 30, 2003: Message edited by: Bert Bates ]
[ April 30, 2003: Message edited by: Bert Bates ]
[ April 30, 2003: Message edited by: Bert Bates ]
[ April 30, 2003: Message edited by: Bert Bates ]

Spot false dilemmas now, ask me how!
(If you're not on the edge, you're taking up too much room.)
peter greaves
Ranch Hand

Joined: Sep 27, 2002
Posts: 51
sort of a guess but...i think the JVM. coherence ideas tell me that the JVM is the information expert about the amount of memory available - and it knows the memmory "cost" of running gc, so it can tell when it is best to respond to the suggestion that System.gc() seems to be. OTOH, the gc's job is to free up memory when called, and do nothing when it isnt tho i am sure other people (esp. those who read the JVM spec ) have better-informed ideas, which i look forward to reading!!

SJCP 1.2
I agree. Here's the link:
subject: Who decides when to reclaim objects?
It's not a secret anymore!