harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject Re: [drlvm] Class unloading support
Date Mon, 30 Oct 2006 14:49:49 GMT

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.  All the C data structures associated with a class loader (classes,
vtables, etc) are "malloc()ed" out of the associated memory manager.  When
the class loader becomes unreachable, then its associated memory manager is
deallocated which automatically frees all the associated C structs (classes,
vtables, etc.)

Does it make sense to try to implement Etienne's scheme?

On 10/30/06, Etienne Gagnon <egagnon@sablevm.org> wrote:
> >>> If I get it right, in case of automagic unloading, GC does all the job
> >>> without a knowledge whether it collects a class, a classloader or
> >>> whatever else.
> >>> Perhaps I'm missing something, but to provide a callback on class
> >>> unloading, the GC must know the semantic of the object being
> collected.
> 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.
> The JVM spec says quite clearly:
> 2.17.8 Unloading of Classes and Interfaces
> A class or interface may be unloaded if and only if its class loader is
> unreachable. The bootstrap class loader is always reachable; as a
> result, system classes may never be unloaded.
> Just think about it.  One could take an instance "o" of a class C loaded
> by L, call it (C,L), and call o.getClass().hashcode().  Store this
> integer some where.  Then, "o" could die, and maybe (C,L) unloaded while
> L is still reachable.  As L is still reachable, some code could do a
> L.findClass("C").hashcode().  This will likely result in a different
> hashcode, in full breach of the both the VM and API specifications.
> In a related note, for memory management I highly encourage Drlvm to
> look at Chapter 3 of http://sablevm.org/people/egagnon/gagnon-phd.pdf
> that exposes a simple, yet very effective approach for managing
> class-loader related memory (i.e. memory used to store internal class
> data, vtables, jitted code) so that it can all be freed efficiently at
> class-loader unloading time.
> Etienne
> --
> Etienne M. Gagnon, Ph.D.            http://www.info2.uqam.ca/~egagnon/
> SableVM:                                       http://www.sablevm.org/
> SableCC:                                       http://www.sablecc.org/

Weldon Washburn
Intel Enterprise Solutions Software Division

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