harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Salikh Zakirov <Salikh.Zaki...@Intel.com>
Subject Re: [drlvm] Class unloading support - tested one approach
Date Thu, 09 Nov 2006 17:17:24 GMT
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
  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.

View raw message