harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xiao-Feng Li" <xiaofeng...@gmail.com>
Subject Re: [DRLVM] proposal to port MMTK to drlvm
Date Thu, 25 May 2006 02:11:45 GMT
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 <ivan.volosyuk@gmail.com> 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 <csdread@gmail.com>:
> > 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: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>

---------------------------------------------------------------------
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


Mime
View raw message