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 On 5/25/06, Ivan Volosyuk <[EMAIL PROTECTED]> wrote:
Agree. We have the GC interfaces declared in: vm/include/open/gc.h vm/include/open/vm_gc.h The interfaces hide implementation of VM, providing functionality to get root set in stop-the-world state, callbacks for object allocation and write barriers. Please, take a look at it. If you have questions, suggestions, extension feel free to ask. -- Ivan 2006/5/25, Daniel Feinberg <[EMAIL PROTECTED]>: > So i have something to chime in with. Since this could be simple from > the beginning and grow more complex as we develop it, we could start > with an interface to the VM. This part is fairly isolated in the code. > I think that as a starting point would be good. > > What does everybody else think? > > Daniel --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
