According to the JVM specification, VM must call non-trivial finalization methods before reclaiming the spaced used by object. Java API specification adds more requiremens by stating that soft references must be cleared before weak references, weak references must be cleared before object becomes eligible for finalization, and that phantom references must be cleared last. JNI specification adds a little bit more by specifying global weak references strength to be about the same as phantom reference strengh, however, without requiring any particular interaction from them. (In the code we sometimes refer to weak references as short weak references, and call JNI weak global references long weak references.
- See also:
gc_add_weak_root_set_entry()
for more details
The requirements described above can be met using following algorithm.
- All weak reference classes can be identified on the stage of class preparation, when VM calls
gc_class_prepared()
callback.
- We start marking with regular (strong) roots, and traverse only strong references. During the process of marking all objects of the reference classes are collected to the reference lists. As we traverse only strong references, only strongly reachable reference will be scheduled for clearing and enqueueing.
- At the end of marking we have strongly reachable objects marked. Unmarked objects may be any of softly, weakly, f-, or phantomly reachable.
- Then we consider all strongly reachable soft references, and make a decision on whether we need to clear them, based on the pending allocation request (if any), the current heap size, the information collected during marking and information about general GC dynamics.
- Soft references which were chosen for clearing are reset, and other soft references are retraced, this time by both strong and soft references. Technically speaking, we add soft reference object pointers to the roots array, and add referent offset to the reference field array of SoftReference class, then restart regular mark task. During this trace, all softly reachable objects will be marked, and all softly (and strongly reachable) weak reference objects collected in a reference list.
- Next we consider the list of weak references, and clear the references which point to dead (unmarked) objects. Note, that ordering of handling of soft and weak references is important and gives as the guarantees required by the Java specifications.
- Short weak root handling is similar to weak references.
- Finalizable objects are considered to find out objects, which became unreachable during this collection. Objects to be finalized are then revived by adding the finalizable queue to the root set and restarting mark process.
- Phantom references are considered, and the references to unmarked objects are cleared.
- Long weak roots are handled in exactly the same way as short weak roots.
- Note, that as the references are cleared, they are also added to the list of references to be enqueued. This list is later transferred to the VM using
vm_enqueue_reference()
function.
- Weak reference objects require special handling of their referent field, because it needs to be reported as an updatable slot before compaction. This is performed as a last step, when we have a guarantee that all unmarked objects are dead at that moment.
Current implementation of weak references places the following requirements
- All reference objects must have exactly one non-regulur object reference, and this reference must be at the same offset for references of all types. GC calls
class_is_reference()
to find out whether the class represents weak reference and finds out the referent offset by calling VM function class_get_referent_offset()
. Note, that referent offset being constant for all kinds of references is not enforced by this interface.
- VM must not enqueue references during call of
vm_enqueue_reference()
because this may lead to deadlocks on reference queue monitors due to the fact that vm_enqueue_reference()
is called during stop-the-world phase of garbage collection.
Genereated on Tue Mar 11 19:25:34 2008 by Doxygen.
(c) Copyright 2005, 2008 The Apache Software Foundation or its licensors, as applicable.