Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (herse.apache.org: domain of gcjhd-harmony-dev@m.gmane.org
 designates 80.91.229.2 as permitted sender)
To: harmony-dev@incubator.apache.org
From: Salikh Zakirov <Salikh.Zakirov@Intel.com>
Subject: Re: [drlvm] Class unloading support - tested one approach
Date: Thu, 09 Nov 2006 20:17:24 +0300
Lines: 43
Message-ID: <eivnr4$udf$1@sea.gmane.org>
References: <5836de490610240251p120dfa56x736fbb5eb1898aca@mail.gmail.com>
	 <4551B15B.2070101@anu.edu.au>
	 <5836de490611080250l6dfbd38cw8778f7a055373d82@mail.gmail.com>
	 <4551B83D.9020706@anu.edu.au>
 <4551CBDB.90004@anu.edu.au>	 <f944d83d0611082328s4d3fa75bm612e4de59719ac80@mail.gmail.com>
	 <f944d83d0611082342y1f45ba48lfcfaca99dbe70c4b@mail.gmail.com>
	 <f944d83d0611090022h3bcf1f6fudec3e27330771f19@mail.gmail.com>
	 <45531ED7.7030904@sablevm.org> <455324E1.2040301@anu.edu.au>
 <f944d83d0611090720q5719f9dcv50b2ac26c17aa8d4@mail.gmail.com>
 <eivjo5$cut$1@sea.gmane.org> <45535741.2080207@sablevm.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
In-Reply-To: <45535741.2080207@sablevm.org>
Sender: news <news@sea.gmane.org>

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.