Re: Fwd: [DRLVM] proposal to port MMTK to drlvm

[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

Re: Fwd: [DRLVM] proposal to port MMTK to drlvm

[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