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/
signature.asc
Description: OpenPGP digital signature
