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 <[EMAIL PROTECTED]> 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/
