> > Robin, > > Over the last few days as we have all been discussing > heap and GC, I have been growing mroe curious by the > hour about what you see as a design critique of the GC > hooks I defined. Perhaps I am taking it a bit too simplistically, > but all I did was define a GC hook anywhere an object or > array reference or a class load or unload happened. How > does your concept differ? And what sort of approach should > be used instead. GC is a completely new area to me and I > am very interested in learning about what could be done. > One of these days I'm going to read the standard (Jones?) > book on JVM garbage collecition, but not today. > > Even if you don't have your proposal ready now, I'm still > interested in hearing how you approach the foundation of > GC design and how you would approach it on this JVM. > > > Dan Lydick
In the garbage collectors I've worked with, the essential design is: - 'new' allocates space on the heap. - The header of each object contains a pointer (or equiv) to a per-class data structure, that points to the GC map for the object (and virtual dispatch tables etc etc) - Reference fields in objects contain pointers directly to the heap objects they reference. - Pointer loads and stores are (optionally) performed via barriers - the terminology is a little confusing: these are not synchronization barriers, but opportunities for the GC to intercept the load/store and do some additional processing. Write barriers are common, read barriers less so. - There are many styles of collector, but the most common class uses tracing, in which a root set of pointers is used to determine an initial set of live objects, and the collector performs a transitive closure over this set to establish the set of all live objects. The root set is commonly the thread stacks and the static pointer fields. - The above is also complicated by . Reference types . Finalization . Locks . Address-based hashing The solutions to these are all pretty well known, but complicate the design This is pretty much it - the rest (45 years of research) is optimizing the way this is all done. > Perhaps I am taking it a bit too simplistically, > but all I did was define a GC hook anywhere an object or > array reference or a class load or unload happened. How > does your concept differ? And what sort of approach should > be used instead. This I think brings us back to my initial question, asking what these hooks were supposed to do. I guess you're saying you had a vague idea that the GC might need to know about these events, so put hooks in for them. When I was looking around the code trying to find out where to start hooking in a managed heap, I looked for the 'new' or 'alloc' operation, and couldn't seem to find it. Interface design for memory managers is an interesting research question. Weldon has posted the ORP interface, which I think is probably pretty close to a good design. I would make some additional operations explicit in the interface, and abstract over some of the features that are a 'shared understanding' between GC and VM in the ORP design, but I think a final design would have a lot in common with it. The MMTk interface is the one I know best, and while it isn't perfect in itself, my improvements to the ORP design would probably involve taking features from the MMTk interface and adapting them to the environment. > be used instead. GC is a completely new area to me and I > am very interested in learning about what could be done. > One of these days I'm going to read the standard (Jones?) > book on JVM garbage collecition, but not today. Yep - Jones and Lins is the standard reference. If you're looking for a good brief introduction, you could do much worse than the wikipedia entry, which seems to cover most of the important parts. > Even if you don't have your proposal ready now, I'm still > interested in hearing how you approach the foundation of > GC design and how you would approach it on this JVM. I think its important that the initial interface contains all the features that have ramifications for the core design ideas of the rest of the system. Hope to have a draft out next week. cheers, Robin
