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 EJB 3 in Action this week in the EJB and other Java EE Technologies 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
Author

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
author
Sheriff

Joined: Oct 14, 2002
Posts: 8764
    
    5
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,

http://java.sun.com/products/hotspot/docs/whitepaper/Java_Hotspot_v1.4.1/Java_HSpot_WP_v1.4.1_1002_2.html#garbage

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
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Who decides when to reclaim objects?
 
Similar Threads
Another question on GC
GC
Will garbage collector run on the spot
Garbage Collection - Boone's Mock Q
GC - Thread safe