Excellent! Looks like GC is the favorite part of VM :) I also has an implementation of GC with better performance then GC_V4, which is currently used in DRLVM. With MMTk there will be a bunch of options to select.
It is really interesting to have GC written in Java. I thought about it. Potentially, dynamicly compiled GC can give much more flexability and performance. I am looking forward to see the prototype. -- Ivan 2006/5/25, Xiao-Feng Li <[EMAIL PROTECTED]>:
We have developed a GC prototype written in Java, which can work with DRLVM to run SPECJVM98. 1. The key idea of this work is not the GC itself (as a prototype), but the Java GC adapter. The idea is, we made the interface for C VM <-> Java GC interactions as an seperate adapter, so that hopefully different Java GCs can plugin to Harmony through this adapter. From Java GC side, it assumes all the interfaces it needs are written in Java; from the C VM side, it assumes all the interfaces to GC are written in C. So basically we need a Java class for the GC to VM invocation, and a C file to bridge the VM to GC invocation. 2. Another key idea of our approach is, it does not prebuild the Java GC as an image. Instead, we let the JVM itself to load the Java GC classes at runtime, and hook all the interfaces. This has a couple of implications: a) We need a JVM builtin primitive GC (I call it Root GC) to hold the preloaded Java objects and the Java GC objects. Root GC can be called as memory manager as well. b) With Root GC, we can enable the on-site debugging of Java GC with print support. The print support in Java GC requires Java string object to be generated. But theoretically collection is only happening when there is no heap to accomodate Java objects. Root GC can be used to hold the GC-time allocated objects. c) More GC adaptability can be achieved with Root GC, since the JVM can not only change the GC's configuration, but also replace the GC module at runtime. This is not necessarily a desirable feature to many users, but I think it doesn't hurt to have it if without any sacrifice. d) The pure runtime loading of a Java GC module means the JVM treats it partially as application code. It might be possible to debug the Java GC module as an application in Eclipse. Once this is achieved, it will largely ease the development of JVM modules in Java. Our prototype is very preliminary and based on the gc_mf bounded with DRLVM. It is still far from being complete regarding all the ideas above. If people think those are interesting, we'd like to contribute our work to Harmony after code cleanup. Thanks, xiaofeng == Intel Middleware Products Division
--------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]