Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: unknown (asf.osuosl.org: error in processing during lookup of
 archie@dellroad.org)
Message-ID: <431FA752.8030407@dellroad.org>
Date: Wed, 07 Sep 2005 21:52:02 -0500
From: Archie Cobbs <archie@dellroad.org>
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.3) Gecko/20041129
MIME-Version: 1.0
To: harmony-dev@incubator.apache.org
Subject: Re: [Arch] Class unloading and VM objects reclaim
References: <9623c9a5050907194513922548@mail.gmail.com>
In-Reply-To: <9623c9a5050907194513922548@mail.gmail.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Xiao-Feng Li wrote:
> They are basically two approaches to unload the classes, one is to
> encode the VM object similarly as App object with a header, then GC
> can treat them uniformly (almost); the other approach treats class
> unloading specially, which reclaims a class loader together with all
> its associated VM objects. The former approach can reclaim as more as
> possible VM objects (besides other benefits such as code placement)
> but requires more GC overhead, while the latter approach can reclaim a
> class loader related objects all together if they are arranged
> properly.

You can get the benefits of both approaches using per-class loader
memory areas like SableVM and JCVM. Each class loader has it's own
stack of memory. All loader-related memory is allocated from that
stack (including possibly java.lang.Class objects). Then when you
unload the loader you free the entire stack at once. During GC you
treat a class loader's stack as a single giant object. For more info:
http://jcvm.sourceforge.net/share/jc/doc/jc.html#GC%20and%20Class%20Loaders

Cheers,
-Archie

__________________________________________________________________________
Archie Cobbs      *        CTO, Awarix        *      http://www.awarix.com