Etienne Gagnon wrote:

> "Revival" is only needed if you use the finalization-like approach.  If
> you only do class-unloading GC when the nursery is empty, then no
> revival is needed.  

Ah, I think I got it.

You mean running a minor collection, and then "class unloading" full heap 
collection
sequentially, without any mutator work in between?
Then, the correctness is observed easily:

  1) all mature objects has their vtable marks set to 1
  2) after minor collection, the nursery is empty
  => all live objects already have vtable marks == 1
  
  Thus, if we find a classloader with vtable marks == 0, then it has no object 
instances,
  and its reachability is defined solely by reachability of 
java.lang.ClassLoader instance
  and existence of the method frames, which can be checked, respectively, by
  enumerating class loader roots as weak roots, and scanning stacks.

  Note, that the class loader, which became eligible for unloading during epoch 
N,
  will not be unloaded until the end of the epoch N+1.

However, in the case of non-generational collector, the "minor collection 
followed
by unloading collection" becomes effectively two successive garbage collections.

On the other side, "finalization-like" design goes as follows:

  1) clean vtable marks before "class unloading" collection
  2) enumerate classloader roots as weak and collect array of user classloader 
pointers for later use
     -- let's call it "unload list"
  3) trace the heap 
  4) scan vtable marks and "revive" marked class unloaders, by adding the 
strong root
     from the previously collected "unload list". Remove the revived 
classloaders from unload list.
  5) repeat steps (3) and (4) until there is no classloaders to revive
  6) unload the classloaders, pointed by the "unload list" -- this reclaims 
native resources
  7) let the GC finish collection and reclaim unreachable objects -- this 
reclaims java objects

This design unloads classloaders at the end of the very same epoch when they 
became unloadable.

The voting definitely was premature, as it turns out that even the design under 
discussion
can be elaborated to multiple substantially different designs.

Reply via email to