> I don't see why both methods of memory allocation and clean up may not be > 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 space. 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 overhead. 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 space. 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. cheers
