You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Weldon Washburn <we...@gmail.com> on 2006/05/24 08:08:38 UTC
[DRLVM] proposal to port MMTK to drlvm
Folks,
There were several interesting email chains about Harmony VM and MMTK
last year. This topic died in large part because there was no JVM.
Since then, several JVMs have been donated. I volunteer to do an
initial investigation of porting MMTK to the recent DRLVM donation.
>From a quick grep of the code, it appears that write barriers are only
partially implemented. We will need to make write barriers functional
before many of the features of MMTK can be used. Thoughts?
Weldon
--
Weldon Washburn
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
Fwd: [DRLVM] proposal to port MMTK to drlvm
Posted by Daniel Feinberg <cs...@gmail.com>.
---------- Forwarded message ----------
From: Daniel Feinberg <cs...@gmail.com>
Date: May 24, 2006 2:13 PM
Subject: Re: [DRLVM] proposal to port MMTK to drlvm
To: Weldon Washburn <we...@gmail.com>
Something like a reference counter does not really need a write
barrier. They are mostly used when you are partitioning the heap into
specific regions for objects that fit cirtian specifications. And
again only if you are going to be collecting a region that has
pointers that flow into the collected section of the heap. There might
be other uses of write barriers. Another kind of collector that might
be of interest that i dont believe is included in MMTK though it
should be is the Older First collector which you can get the paper at
the DaCapo website.
Daniel
On 5/24/06, Weldon Washburn <we...@gmail.com> wrote:
> On 5/24/06, Daniel Feinberg <cs...@gmail.com> wrote:
> > > >My understanding of write barriers is as an optimization.
> > > That fits with my understanding of write barriers also. I do not
> > > know for certain but suspect that MMTK can somehow be configured such
> > > that write barriers are not required for correctness. Maybe Dan
> > > Feinberg can tell the mailing list.
> >
> > So MMTK is a toolkit for building GCs. When doing generational
> > collection the write barrier is used to keep track of pointers that go
> > from older generations to yonger generations. You must have a way to
> > track these objects because when you do a partial heap collection (aka
> > just the nursery or nursery and old1) you need to build a root set of
> > all things that point into that space. Then you trace this root set to
> > find all live objects that need to be moved to an older generation. In
> > other methods of collecting the write barrier is not as important.
>
> Thanks. This fits my expectations. One follow-up question. By "not
> as important", do you mean functionally correct but bad performance or
> something else?
>
>
> > Here unless you can find all of these pointers that point into a space
> > from an older space you must use a write barrier.
>
> >
> >
> > 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
> >
> >
>
>
> --
> Weldon Washburn
> Intel Middleware Products Division
>
--
Daniel Feinberg
http://www.cs.unm.edu/~danielf
--
Daniel Feinberg
http://www.cs.unm.edu/~danielf
---------------------------------------------------------------------
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
Re: [DRLVM] proposal to port MMTK to drlvm
Posted by Weldon Washburn <we...@gmail.com>.
On 5/24/06, Daniel Feinberg <cs...@gmail.com> wrote:
> > >My understanding of write barriers is as an optimization.
> > That fits with my understanding of write barriers also. I do not
> > know for certain but suspect that MMTK can somehow be configured such
> > that write barriers are not required for correctness. Maybe Dan
> > Feinberg can tell the mailing list.
>
> So MMTK is a toolkit for building GCs. When doing generational
> collection the write barrier is used to keep track of pointers that go
> from older generations to yonger generations. You must have a way to
> track these objects because when you do a partial heap collection (aka
> just the nursery or nursery and old1) you need to build a root set of
> all things that point into that space. Then you trace this root set to
> find all live objects that need to be moved to an older generation. In
> other methods of collecting the write barrier is not as important.
Thanks. This fits my expectations. One follow-up question. By "not
as important", do you mean functionally correct but bad performance or
something else?
> Here unless you can find all of these pointers that point into a space
> from an older space you must use a write barrier.
>
>
> 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
>
>
--
Weldon Washburn
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
Re: [DRLVM] proposal to port MMTK to drlvm
Posted by Weldon Washburn <we...@gmail.com>.
On 5/24/06, Rodrigo Kumpera <ku...@gmail.com> wrote:
> Note that read barriers are also needed if you want to implement a GC
> like Baker's real time copying collector that uses incremental
> forwarding.
Rodrigo, good point. For initial MMTK bring up, I would like to keep
things as simple as possible. How about ignoring read barriers until
after initial bring up? Also, those on the mailing list who are
interested in read barriers should feel free to jump in.
>
> Rodrigo
>
>
> On 5/24/06, Weldon Washburn <we...@gmail.com> wrote:
> > On 5/24/06, Ivan Volosyuk <iv...@gmail.com> wrote:
> > > I have a patch for drlvm which enables use of write barriers. This
> > > works in interpreter mode only yet. I can put it on jira if somebody
> > > is interested.
> > This is helpful. Please post the patch. I will take a look at it
> > sometime soon.
> > Thanks
> >
> > >The write barriers are tested with an algorithm which
> > > does per-slot validation and should work fine.
> > > --
> > > Ivan
> > >
> > > 2006/5/24, Daniel Feinberg <cs...@gmail.com>:
> > > > > >My understanding of write barriers is as an optimization.
> > > > > That fits with my understanding of write barriers also. I do not
> > > > > know for certain but suspect that MMTK can somehow be configured such
> > > > > that write barriers are not required for correctness. Maybe Dan
> > > > > Feinberg can tell the mailing list.
> > > >
> > > > So MMTK is a toolkit for building GCs. When doing generational
> > > > collection the write barrier is used to keep track of pointers that go
> > > > from older generations to yonger generations. You must have a way to
> > > > track these objects because when you do a partial heap collection (aka
> > > > just the nursery or nursery and old1) you need to build a root set of
> > > > all things that point into that space. Then you trace this root set to
> > > > find all live objects that need to be moved to an older generation. In
> > > > other methods of collecting the write barrier is not as important.
> > > > Here unless you can find all of these pointers that point into a space
> > > > from an older space you must use a write barrier.
> > > >
> > > >
> > > > 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
> > >
> > >
> >
> >
> > --
> > Weldon Washburn
> > 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
> >
> >
>
> ---------------------------------------------------------------------
> 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
>
>
--
Weldon Washburn
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
Re: [DRLVM] proposal to port MMTK to drlvm
Posted by Rodrigo Kumpera <ku...@gmail.com>.
Note that read barriers are also needed if you want to implement a GC
like Baker's real time copying collector that uses incremental
forwarding.
Rodrigo
On 5/24/06, Weldon Washburn <we...@gmail.com> wrote:
> On 5/24/06, Ivan Volosyuk <iv...@gmail.com> wrote:
> > I have a patch for drlvm which enables use of write barriers. This
> > works in interpreter mode only yet. I can put it on jira if somebody
> > is interested.
> This is helpful. Please post the patch. I will take a look at it
> sometime soon.
> Thanks
>
> >The write barriers are tested with an algorithm which
> > does per-slot validation and should work fine.
> > --
> > Ivan
> >
> > 2006/5/24, Daniel Feinberg <cs...@gmail.com>:
> > > > >My understanding of write barriers is as an optimization.
> > > > That fits with my understanding of write barriers also. I do not
> > > > know for certain but suspect that MMTK can somehow be configured such
> > > > that write barriers are not required for correctness. Maybe Dan
> > > > Feinberg can tell the mailing list.
> > >
> > > So MMTK is a toolkit for building GCs. When doing generational
> > > collection the write barrier is used to keep track of pointers that go
> > > from older generations to yonger generations. You must have a way to
> > > track these objects because when you do a partial heap collection (aka
> > > just the nursery or nursery and old1) you need to build a root set of
> > > all things that point into that space. Then you trace this root set to
> > > find all live objects that need to be moved to an older generation. In
> > > other methods of collecting the write barrier is not as important.
> > > Here unless you can find all of these pointers that point into a space
> > > from an older space you must use a write barrier.
> > >
> > >
> > > 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
> >
> >
>
>
> --
> Weldon Washburn
> 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
>
>
---------------------------------------------------------------------
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
Re: [DRLVM] proposal to port MMTK to drlvm
Posted by Weldon Washburn <we...@gmail.com>.
On 5/24/06, Xiao-Feng Li <xi...@gmail.com> wrote:
> We have developed a GC prototype written in Java, which can work with
> DRLVM to run SPECJVM98.
This is good. Please put the rough prototype in a zip file and post
to Harmony JIRA. It would be good to look at even an early, rough
version while we plan the MMTK port. Ultimately, we might be able to
use part or all of this code. We should have a discussion about this
code on harmony-dev.
I assume this prototype is a clean room implementation which can be
donated under the bulk contribution mechanism. Also, do you have any
documentation for this Java GC Adapter yet?
--
Weldon Washburn
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
Re: [DRLVM] proposal to port MMTK to drlvm
Posted by Ivan Volosyuk <iv...@gmail.com>.
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 <xi...@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
Re: [DRLVM] proposal to port MMTK to drlvm
Posted by Xiao-Feng Li <xi...@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
On 5/25/06, Ivan Volosyuk <iv...@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 <cs...@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
Re: [DRLVM] proposal to port MMTK to drlvm
Posted by Weldon Washburn <we...@gmail.com>.
On 5/24/06, Ivan Volosyuk <iv...@gmail.com> wrote:
> Agree. We have the GC interfaces declared in:
hmm... who is the "we"? Perhaps you are referring to Harmony DRLVM
donation. Incidentally, my original question about MMTK interface
> 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.
OK. Will do. Thanks again.
Incidentally, how do I ask Apache legal to tell us if MMTK license is
compatible with Apache? I'd hate to start a port of MMTK to Harmony
JVM only to find out that the end-product can not be checked-in to
Apache svn.
> --
> Ivan
>
> 2006/5/25, Daniel Feinberg <cs...@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
>
>
--
Weldon Washburn
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
Fwd: [DRLVM] proposal to port MMTK to drlvm
Posted by Daniel Feinberg <cs...@gmail.com>.
---------- Forwarded message ----------
From: Daniel Feinberg <cs...@gmail.com>
Date: May 24, 2006 7:04 PM
Subject: Re: [DRLVM] proposal to port MMTK to drlvm
To: Ivan Volosyuk <iv...@gmail.com>
This is good. The JikesRVM and MMTK code is also built like this with
an interface between the two. You can find the code in:
$RVM_ROOT/rvm/src/vm/memoryManagers/JMTk/vmInterface/
the file is:
MM_Interface.java
This file is the direct interface to the GC. This file and some others
in that one directory are the only files left that are used from JMTk.
(This i believe holds true in the newest versions but i have not
worked with it in 1 year.) The rest are in the MMTk sub dir above the
vm dir of the $RVM_ROOT directory.
I dont know if this is helpful.
On 5/24/06, Ivan Volosyuk <iv...@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 <cs...@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
>
--
Daniel Feinberg
http://www.cs.unm.edu/~danielf
--
Daniel Feinberg
http://www.cs.unm.edu/~danielf
---------------------------------------------------------------------
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
Re: [DRLVM] proposal to port MMTK to drlvm
Posted by Ivan Volosyuk <iv...@gmail.com>.
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 <cs...@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
Re: [DRLVM] proposal to port MMTK to drlvm
Posted by Weldon Washburn <we...@gmail.com>.
On 5/24/06, Daniel Feinberg <cs...@gmail.com> wrote:
> 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.
The "start simple and grow more complex" seems logical. I like it.
But I am curious about an interface to VM vs an interface to (?)
>
> 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
>
>
--
Weldon Washburn
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
Re: [DRLVM] proposal to port MMTK to drlvm
Posted by Daniel Feinberg <cs...@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
Re: [DRLVM] proposal to port MMTK to drlvm
Posted by Ivan Volosyuk <iv...@gmail.com>.
2006/5/25, Weldon Washburn <we...@gmail.com>:
> On 5/24/06, Ivan Volosyuk <iv...@gmail.com> wrote:
> > I have a patch for drlvm which enables use of write barriers. This
> > works in interpreter mode only yet. I can put it on jira if somebody
> > is interested.
> This is helpful. Please post the patch. I will take a look at it
> sometime soon.
JIRA HARMONY-504
--
Ivan
---------------------------------------------------------------------
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
Re: [DRLVM] proposal to port MMTK to drlvm
Posted by Weldon Washburn <we...@gmail.com>.
On 5/24/06, Ivan Volosyuk <iv...@gmail.com> wrote:
> I have a patch for drlvm which enables use of write barriers. This
> works in interpreter mode only yet. I can put it on jira if somebody
> is interested.
This is helpful. Please post the patch. I will take a look at it
sometime soon.
Thanks
>The write barriers are tested with an algorithm which
> does per-slot validation and should work fine.
> --
> Ivan
>
> 2006/5/24, Daniel Feinberg <cs...@gmail.com>:
> > > >My understanding of write barriers is as an optimization.
> > > That fits with my understanding of write barriers also. I do not
> > > know for certain but suspect that MMTK can somehow be configured such
> > > that write barriers are not required for correctness. Maybe Dan
> > > Feinberg can tell the mailing list.
> >
> > So MMTK is a toolkit for building GCs. When doing generational
> > collection the write barrier is used to keep track of pointers that go
> > from older generations to yonger generations. You must have a way to
> > track these objects because when you do a partial heap collection (aka
> > just the nursery or nursery and old1) you need to build a root set of
> > all things that point into that space. Then you trace this root set to
> > find all live objects that need to be moved to an older generation. In
> > other methods of collecting the write barrier is not as important.
> > Here unless you can find all of these pointers that point into a space
> > from an older space you must use a write barrier.
> >
> >
> > 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
>
>
--
Weldon Washburn
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
Re: [DRLVM] proposal to port MMTK to drlvm
Posted by Ivan Volosyuk <iv...@gmail.com>.
I have a patch for drlvm which enables use of write barriers. This
works in interpreter mode only yet. I can put it on jira if somebody
is interested. The write barriers are tested with an algorithm which
does per-slot validation and should work fine.
--
Ivan
2006/5/24, Daniel Feinberg <cs...@gmail.com>:
> > >My understanding of write barriers is as an optimization.
> > That fits with my understanding of write barriers also. I do not
> > know for certain but suspect that MMTK can somehow be configured such
> > that write barriers are not required for correctness. Maybe Dan
> > Feinberg can tell the mailing list.
>
> So MMTK is a toolkit for building GCs. When doing generational
> collection the write barrier is used to keep track of pointers that go
> from older generations to yonger generations. You must have a way to
> track these objects because when you do a partial heap collection (aka
> just the nursery or nursery and old1) you need to build a root set of
> all things that point into that space. Then you trace this root set to
> find all live objects that need to be moved to an older generation. In
> other methods of collecting the write barrier is not as important.
> Here unless you can find all of these pointers that point into a space
> from an older space you must use a write barrier.
>
>
> 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
Re: [DRLVM] proposal to port MMTK to drlvm
Posted by Daniel Feinberg <cs...@gmail.com>.
> >My understanding of write barriers is as an optimization.
> That fits with my understanding of write barriers also. I do not
> know for certain but suspect that MMTK can somehow be configured such
> that write barriers are not required for correctness. Maybe Dan
> Feinberg can tell the mailing list.
So MMTK is a toolkit for building GCs. When doing generational
collection the write barrier is used to keep track of pointers that go
from older generations to yonger generations. You must have a way to
track these objects because when you do a partial heap collection (aka
just the nursery or nursery and old1) you need to build a root set of
all things that point into that space. Then you trace this root set to
find all live objects that need to be moved to an older generation. In
other methods of collecting the write barrier is not as important.
Here unless you can find all of these pointers that point into a space
from an older space you must use a write barrier.
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
Re: [DRLVM] proposal to port MMTK to drlvm
Posted by Weldon Washburn <we...@gmail.com>.
On 5/24/06, Rana Dasgupta <rd...@gmail.com> wrote:
> Hi Weldon,
> Does your research show that MMTk has a functional dependency on Write
> Barriers?
Good question. I want to play by Apache rules. I am waiting for
Apache legal to inform us if we can port MMTK to an Apache Harmony
JVM.
>My understanding of write barriers is as an optimization.
That fits with my understanding of write barriers also. I do not
know for certain but suspect that MMTK can somehow be configured such
that write barriers are not required for correctness. Maybe Dan
Feinberg can tell the mailing list.
>Also,
> the contribution GC is not generational. So..I am not sure how this would be
> tested etc.
>
> Thanks,
> Rana
>
>
> On 5/23/06, Weldon Washburn <we...@gmail.com> wrote:
> >
> > Folks,
> >
> > There were several interesting email chains about Harmony VM and MMTK
> > last year. This topic died in large part because there was no JVM.
> > Since then, several JVMs have been donated. I volunteer to do an
> > initial investigation of porting MMTK to the recent DRLVM donation.
> > From a quick grep of the code, it appears that write barriers are only
> > partially implemented. We will need to make write barriers functional
> > before many of the features of MMTK can be used. Thoughts?
> >
> > Weldon
> >
> >
> >
> > --
> > Weldon Washburn
> > 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
> >
> >
>
>
--
Weldon Washburn
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
Re: [DRLVM] proposal to port MMTK to drlvm
Posted by Rana Dasgupta <rd...@gmail.com>.
Hi Weldon,
Does your research show that MMTk has a functional dependency on Write
Barriers? My understanding of write barriers is as an optimization. Also,
the contribution GC is not generational. So..I am not sure how this would be
tested etc.
Thanks,
Rana
On 5/23/06, Weldon Washburn <we...@gmail.com> wrote:
>
> Folks,
>
> There were several interesting email chains about Harmony VM and MMTK
> last year. This topic died in large part because there was no JVM.
> Since then, several JVMs have been donated. I volunteer to do an
> initial investigation of porting MMTK to the recent DRLVM donation.
> From a quick grep of the code, it appears that write barriers are only
> partially implemented. We will need to make write barriers functional
> before many of the features of MMTK can be used. Thoughts?
>
> Weldon
>
>
>
> --
> Weldon Washburn
> 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
>
>
Fwd: [DRLVM] proposal to port MMTK to drlvm
Posted by Weldon Washburn <we...@gmail.com>.
oops. I forgot to cc:
---------- Forwarded message ----------
From: Weldon Washburn <we...@gmail.com>
Date: May 24, 2006 6:43 AM
Subject: Re: [DRLVM] proposal to port MMTK to drlvm
To: danielf@cs.unm.edu
Daniel,
I really appreciate your offer to help. On the surface, our
backgrounds are complementary. I know very little about MMTK.
However, I know something about the Harmony project and the DRLVM that
was donated to Harmony.
I plan to download MMTK source code soon and take a look so that I can
ask you intelligent questions. It would be great if you have the time
to download Harmony DRLVM source and also have a look.
Thanks
Weldon
On 5/23/06, Daniel Feinberg <cs...@gmail.com> wrote:
> I would like to help. I have experiance with MMTK as i did research
> with it for a long time in the DeCapo Group with Darko S. at UNM.
>
> Let me know what i can do. I dont have much experiance with Harmony
> but i dont know if that will matter.
>
> On 5/24/06, Weldon Washburn <we...@gmail.com> wrote:
> > Folks,
> >
> > There were several interesting email chains about Harmony VM and MMTK
> > last year. This topic died in large part because there was no JVM.
> > Since then, several JVMs have been donated. I volunteer to do an
> > initial investigation of porting MMTK to the recent DRLVM donation.
> > From a quick grep of the code, it appears that write barriers are only
> > partially implemented. We will need to make write barriers functional
> > before many of the features of MMTK can be used. Thoughts?
> >
> > Weldon
> >
> >
> >
> > --
> > Weldon Washburn
> > 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
> >
> >
>
>
> --
> Daniel Feinberg
> http://www.cs.unm.edu/~danielf
>
--
Weldon Washburn
Intel Middleware Products Division
--
Weldon Washburn
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
Re: Fwd: [DRLVM] proposal to port MMTK to drlvm
Posted by Weldon Washburn <we...@gmail.com>.
On 6/14/06, Robin Garner <ro...@anu.edu.au> wrote:
> The port to rotor was done by Andrew Gray at ANU, and was based on my
> work integrating MMTk into C-based runtimes. The approach used was to
> apply a source code transformation to turn the MMTk 'magic' into native
> methods (using CNI) on primitive types, and compile MMTk with gcj. It
> is described in detail in my honours thesis.
This confirms what I saw in the code. A bunch more pieces are falling
into place. We will probably won't use GCJ or CNI. Instead, I am
thinking of JITing MMTk at boot time just before calling GC init().
This will slow down boot but hopefully not make booting unbearable for
developers. The hope is that it will be easy to put intrinsics into
the JIT, jitrino.jet for all the classes in the unboxed package. Its
sort of "inlining" but not in the traditional sense.
>
> The source transformer code is licensed as public domain, but would need
> considerable modification to work on the current MMTk code base. A far
> better approach would be to implement the vmmagic types in gcj.
Or with a *.class to binary image compiler mentioned above.
> The
> bulk of the C code in the interface to Rotor is specific to rotor, and
> would need to be re-implemented for DRLVM anyway.
Agreed. It might be nice to take a peek at the Rotor code to get
ideas on how things could be implemented.
>
> The MMTk <-> VM interface is much cleaner these days: as Daniel points
> out, MM_Interface defines the JikesRVM -> MMTk interface, and MMTk's
> interface to the vm is the package org.mmtk.vm.
I am reading all the interface code now. I hope to have a general
outline of the MMTk to drlvm port in a few days. I would be much
appreciated if you can review it and tell me what to fix.
> MMTk is compiled to a
> JAR file against stubs for this package, and the directory ext/JikesRVM
> contains the JikesRVM-specific implementation of the interface.
Its good to learn this. A first step will be to compile MMTk all by
itself and put all of it in a JAR file.
By the way, do you know how much effort it was to port MMTK to Rotor?
Thanks for all the help.
Weldon
--
Weldon Washburn
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
Re: Fwd: [DRLVM] proposal to port MMTK to drlvm
Posted by Robin Garner <ro...@anu.edu.au>.
Weldon Washburn wrote:
> oops, I forgot to cc:
>
> ---------- Forwarded message ----------
> From: Weldon Washburn <we...@gmail.com>
> Date: May 24, 2006 11:23 AM
> Subject: Re: [DRLVM] proposal to port MMTK to drlvm
> To: danielf@cs.unm.edu
>
>
> On 5/24/06, Daniel Feinberg <cs...@gmail.com> wrote:
>> that is cool, so the other thing i was thinking about is that MMTK is
>> written for JikesRVM which is a meta-circular java implementation. AKA
>> it is written in java with some magic for the low level mem stuff. I
>> am not sure how that would integrate into Harmoney and the DRLVM. I
>> dont think it would be hard to port it to another language or we could
>> write some sort of interface to bridge the two. Not sure what are your
>> ideas?
>
> hmm.... somewhere I heard that MMTK had been ported to Microsoft
> Rotor. I know Rotor is a vm written in C/C++. If this port is under
> an Apache agreeable license, then we could look at this code. If no
> MMTK-to-C interface that is compatible with Apache license exists
> then, of course, we will need to build one. My preference would be to
> keep it the interface combinations to C and Java. I would rather not
> bog down MMTK/HarmonyDRLVM with any C++ distractions initially. I
> think the initial focus is functionality, cleaning up the C interface,
> then performance.
The port to rotor was done by Andrew Gray at ANU, and was based on my
work integrating MMTk into C-based runtimes. The approach used was to
apply a source code transformation to turn the MMTk 'magic' into native
methods (using CNI) on primitive types, and compile MMTk with gcj. It
is described in detail in my honours thesis.
The source transformer code is licensed as public domain, but would need
considerable modification to work on the current MMTk code base. A far
better approach would be to implement the vmmagic types in gcj. The
bulk of the C code in the interface to Rotor is specific to rotor, and
would need to be re-implemented for DRLVM anyway.
The MMTk <-> VM interface is much cleaner these days: as Daniel points
out, MM_Interface defines the JikesRVM -> MMTk interface, and MMTk's
interface to the vm is the package org.mmtk.vm. MMTk is compiled to a
JAR file against stubs for this package, and the directory ext/JikesRVM
contains the JikesRVM-specific implementation of the interface.
cheers
---------------------------------------------------------------------
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
Fwd: [DRLVM] proposal to port MMTK to drlvm
Posted by Weldon Washburn <we...@gmail.com>.
oops, I forgot to cc:
---------- Forwarded message ----------
From: Weldon Washburn <we...@gmail.com>
Date: May 24, 2006 11:23 AM
Subject: Re: [DRLVM] proposal to port MMTK to drlvm
To: danielf@cs.unm.edu
On 5/24/06, Daniel Feinberg <cs...@gmail.com> wrote:
> that is cool, so the other thing i was thinking about is that MMTK is
> written for JikesRVM which is a meta-circular java implementation. AKA
> it is written in java with some magic for the low level mem stuff. I
> am not sure how that would integrate into Harmoney and the DRLVM. I
> dont think it would be hard to port it to another language or we could
> write some sort of interface to bridge the two. Not sure what are your
> ideas?
hmm.... somewhere I heard that MMTK had been ported to Microsoft
Rotor. I know Rotor is a vm written in C/C++. If this port is under
an Apache agreeable license, then we could look at this code. If no
MMTK-to-C interface that is compatible with Apache license exists
then, of course, we will need to build one. My preference would be to
keep it the interface combinations to C and Java. I would rather not
bog down MMTK/HarmonyDRLVM with any C++ distractions initially. I
think the initial focus is functionality, cleaning up the C interface,
then performance.
>
> On 5/24/06, Weldon Washburn <we...@gmail.com> wrote:
> > On 5/24/06, Daniel Feinberg <cs...@gmail.com> wrote:
> > > yes that would be fine. Do you use skype or another communication
> > > service.
> > I don't have skype installed. However, if the phone call is around
> > the US, I have cell phone and land line that don't have long distance
> > fees. I will send phone numbers to you directly.
> >
> > That way we can talk about this kind of stuff.
> > >
> > >
> > >
> > > On 5/24/06, Weldon Washburn <we...@gmail.com> wrote:
> > > > Daniel,
> > > >
> > > > I really appreciate your offer to help. On the surface, our
> > > > backgrounds are complementary. I know very little about MMTK.
> > > > However, I know something about the Harmony project and the DRLVM that
> > > > was donated to Harmony.
> > > >
> > > > I plan to download MMTK source code soon and take a look so that I can
> > > > ask you intelligent questions. It would be great if you have the time
> > > > to download Harmony DRLVM source and also have a look.
> > > >
> > > > Thanks
> > > > Weldon
> > > >
> > > >
> > > > On 5/23/06, Daniel Feinberg <cs...@gmail.com> wrote:
> > > > > I would like to help. I have experiance with MMTK as i did research
> > > > > with it for a long time in the DeCapo Group with Darko S. at UNM.
> > > > >
> > > > > Let me know what i can do. I dont have much experiance with Harmony
> > > > > but i dont know if that will matter.
> > > > >
> > > > > On 5/24/06, Weldon Washburn <we...@gmail.com> wrote:
> > > > > > Folks,
> > > > > >
> > > > > > There were several interesting email chains about Harmony VM and MMTK
> > > > > > last year. This topic died in large part because there was no JVM.
> > > > > > Since then, several JVMs have been donated. I volunteer to do an
> > > > > > initial investigation of porting MMTK to the recent DRLVM donation.
> > > > > > From a quick grep of the code, it appears that write barriers are only
> > > > > > partially implemented. We will need to make write barriers functional
> > > > > > before many of the features of MMTK can be used. Thoughts?
> > > > > >
> > > > > > Weldon
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Weldon Washburn
> > > > > > 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
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Daniel Feinberg
> > > > > http://www.cs.unm.edu/~danielf
> > > > >
> > > >
> > > >
> > > > --
> > > > Weldon Washburn
> > > > Intel Middleware Products Division
> > > >
> > >
> > >
> > > --
> > > Daniel Feinberg
> > > http://www.cs.unm.edu/~danielf
> > >
> >
> >
> > --
> > Weldon Washburn
> > Intel Middleware Products Division
> >
>
>
> --
> Daniel Feinberg
> http://www.cs.unm.edu/~danielf
>
--
Weldon Washburn
Intel Middleware Products Division
--
Weldon Washburn
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