harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivan Volosyuk" <ivan.volos...@gmail.com>
Subject Re: [DRLVM] proposal to port MMTK to drlvm
Date Thu, 25 May 2006 12:32:52 GMT
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.

2006/5/25, Xiao-Feng Li <xiaofeng.li@gmail.com>:
> 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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

View raw message