>(1) The decaf JVM we're using uses pointers, not handles, to represent Java >objects (although all Java objects are subclassed from a single C++ base >class >in the JVM so we could probably change this if it became necessary). This >rules >out a whole bunch of "moving" or "copying" GC approaches. That's certainly true if you want conservative gc, but if you know what is a pointer and what is not, then you can update the pointers directly. This is what HotSpot does -- Sun seem vey proud of this fact, so I guess it's not so easy (either that or their marketing dept have been working hard..) See http://developer.java.sun.com/developer/technicalArticles/Networking/HotSpot A moving (compacting like HotSpot?) gc is something I'd maybe like to take a look at later. >(2) The decaf JVM and the jjos nano/pico/femto/whatever kernel uses C++ and >dynamic memory allocation as well. Currently, both the jjos C++ objects and >the >Java objects (which are, after all, C++ objects as far as the JVM is >concerned) >are allocated out of the same heap. I must admit I hadn't considered the heap requirements of the JVM and kernel. I'll get to thinking about what this might mean for JJOS's gc. >(3) The JVM uses "green threads" right now (i.e., simulated, not "real" >threads). However, when the underlying kernel implements native threads, >we're >really going to have both a Java and a native code stack for each Java >thread. >Wouldn't it be nice if we just used a conservative GC to scan both data >structures the same way? This has confused me whenever it's been mentioned on the JOS mailing lists - at the low level of the JOS kernel, is there that much to distinguish native threads and green threads? What benefit is there to the kernel implementing the threads rather than the VM? Explanations welcome .. >This is, to the best of my knowledge, similar to the time-honored >Kaffe-adopted >solution as described at: > http://sourceware.cygnus.com/java/papers/nosb.html I'd not seen this - it seems to be a handy code-level analysis of Kaffe's gc. My source for the mechanism was the Jones' Garbage Collection book. >With respect to design considerations, a couple of not-quite-typical >requirements: > >(1) Currently, decaf does not call destructors (and thence heap >deallocators) >everywhere it is possible to know that the memory object has instantaneously >become garbage. Either Todd or I can track those down so you don't have to. >We >have, of late, become more conscientious about calling destructors. Please >advise us if there is a suitable entry point in your conservative heap >implementation for us to mark a memory block as unused... I hadn't considered calls to the heap to explicitly free memory, since you can't do it from Java, and that's what I was concentrating on. I think it would be helpful to null out pointers when they are known to be rubbish, even if I didn't provide a mechanism for explicit freeing. >(5) Java requires that we call any "finalize" Java methods upon Java objects >prior to their being GC-ed/reclaimed. Todd can perhaps shed more light upon >which context the methods must be executed in ... Again, I've not considered this yet -- I'll have to come back to it after the thing actually manages to gc at all! >> - Look at other types of gc: is generational gc useful for Java? > >Without having either a copying/compacting collector, I don't know right >now... I hadn't read about HotSpot when I asked my question -- Sun certainly seem to think generational is good. >> My guiding light in all this has been "Garbage Collection : Algorithms for >> Automatic Dynamic Memory Management" by Richard Jones and Rafael Lins. >> > >An absolutely fabulous book -- read it cover-to-cover. Please pay >particular >attention to the brief bits about how Lisp Machines availed themselves of >the >special virtual memory hardware to increase performance (I do not have the >book >with me at work, but I recall finding some of these bits via the index). In >particular, I hope that we can scan pages BEFORE they have to get paged out, >as >part of the "regular" paging process, and reclaim instantly those pages >which >only contain garbage, and thus avoid the overhead of "throwing the page over >the >wall" and sleeping any threads at all. This is supposed to be a Really Big >Win. Yes. Because the gc is part of the kernel, I hope that eventually that we can work very closely with the the virtual memory system and take advantage of various gubbins in the memory mgt unit that are inaccessible to user processes. >I have other GC-related URLs, too, if you are interested... One of the best sources I've discovered (only in the last day or two) is ftp://ftp.cs.utexas.edu/pub/garbage. bigsurv.ps is a survey of gc techniques - it covers a lot of the same ground as the Jones' book - and allocsrv.ps covers heap management. Finally, a word of warning: what I've currently written is in C. This is for two reasons: 1) I've never written any C++ 2) I intended to try integrating it with Kaffe for testing purposes. (I'm not sure this is relevant now.) I'll carry on in C until it's up and working. Then I'll try rewriting it in C++ -- should be a good way to learn .. Again, thanks for the warm welcome. -- George _______________________________________________ Kernel maillist - [EMAIL PROTECTED] http://jos.org/mailman/listinfo/kernel
