harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksey Ignatenko" <aleksey.ignate...@gmail.com>
Subject Re: [drlvm] Class unloading support
Date Tue, 31 Oct 2006 03:30:42 GMT
 Hello, Etienne.

>Am I wrong, or does this proposition imply collecting classes
>independently from their class loader?  If this is the case, I have to
>say that I disagree with the proposed approach.

Yes, you are wrong. This proposition implies collection of classloader and
clasess loaded by it at once. You can see what is "class registry" in
the first letter of the discussion -

"Class registry - introduce references from j.l.Classes to its defining
j.l.Classloader and references from j.l.Classloader to j.l.Classes loaded by
it (unloading is to be done for j.l.Classloader and corresponding
j.l.Classes at once)."

And what about gagnon-phd.pdf:
> very effective approach for managing class-loader related memory
Drlvm already has similar functionality: look at classloader.h, function
void* Alloc(size_t size); You'll see that most of classloader's data (not
100% yet) is already allocated from pool of that classloader.

Aleksey.



On 10/30/06, Etienne Gagnon <egagnon@sablevm.org> wrote:
>
> Hi Weldon,
>
> Weldon Washburn wrote:
> > I read section 3.2.3 (Class-Loader-Specific Memory) of gagnon-phd.pdf .
> > Please tell me if the following is a correct interpretation.  You create
> > a new memory manager that is uniquely associated with each new class
> > loader.
>
> Right.
>
> >  All the C data structures associated with a class loader (classes,
> > vtables, etc) are "malloc()ed" out of the associated memory manager.
>
> [For those who have not read it...]
>
> "malloc()ed" is a big word...  It is rather "simpleAlloc()ed", i.e.,
> once allocated, you cannot free it (...or if you do, the "free-list"
> manager is very minimal, performs no checks [you have to tell it how
> much you are freeing] and no aggregation).  I do discuss this in the
> Chapter, of course, and you can look at the implementation in SableVM.
> [The SableVM trunk is under AL2.0 (unlike released versions)].
>
> >  When
> > the class loader becomes unreachable, then its associated memory manager
> is
> > deallocated which automatically frees all the associated C structs
> > (classes, vtables, etc.)
>
> Yep.
>
> Etienne
>
> --
> Etienne M. Gagnon, Ph.D.             http://www.info2.uqam.ca/~egagnon/
> SableVM:                                       http://www.sablevm.org/
> SableCC:                                       http://www.sablecc.org/
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message