harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robin Garner <Robin.Gar...@anu.edu.au>
Subject Re: [Arch] Class unloading and VM objects reclaim
Date Tue, 13 Sep 2005 08:55:14 GMT
> I don't see why both methods of memory allocation and clean up may not
> employed. The classLoader may manage it's own memory area and create
> objects that only it uses in the main memory area. The main memory area
> objects would be true objects and be gc'ed just like normal (So long as
> the class/classloader was given an object sig and registered it's creation
> and release of these like any normal object would) and the local memory
> would be freed when the class/classLoader was removed.

In JikesRVM with MMTk, the issue of where the classloader allocates its
objects is essentially configurable.  You can select by call-site
and/or by class which area of the heap objects are allocated into.  By
default all classloader allocated objects are allocated into the
standard heap, but it's fairly common when doing experiments or
debugging a new collector to allocate these objects into an immortal

While MMTk doesn't (yet) support region-based allocation, it would be
possible to have per-classloader objects allocated into regions, where
they can be freed en masse.  What we can't do at the moment is choose
whether or not to scan these objects at GC time, but my feeling is that
particularly in a generational collector it's not a significant

The point I want to make is that I think a good design should make the
issue of classloader allocation policy configurable, if not at run time
then certainly at build time.

> This also brings up questions as to if we want to control all memory
> allocation in the JVM instance, simply using the OS to increase and
> decrease the JVM size or if the OS will be used to assign separate memory
> areas to separate pieces of the JVM?

MMTk divides up virtual memory by collection policy.  For example, in
the generational mark-sweep collector, 15% of available virtual memory
is set aside at the top end of the available virtual address space for a
nursery, and 60% of virtual memory is set aside for the mature space
(and other areas for large objects, metadata etc).  As objects are
allocated, MMTk requests memory from the OS, mapped into the appropriate

It is useful to be able to specify certain characteristics of the
virtual memory regions, eg that the nursery is at higher addresses,
because the efficiency of the read and write barriers depends on being
able to quickly identify nursery objects, and having the nursery in high
addresses means you can do that with a single comparison.  Other
barriers have other requirements.

Is this what you mean by "the OS will be used to assign separate memory
areas to separate pieces of the JVM" ?  In which case, I'd argue that
it's highly desirable.


View raw message