harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robin Garner <robin.gar...@anu.edu.au>
Subject Re: Fwd: [DRLVM] proposal to port MMTK to drlvm
Date Thu, 15 Jun 2006 05:11:05 GMT
Weldon Washburn wrote:
> oops, I forgot to cc:
> ---------- Forwarded message ----------
> From: Weldon Washburn <weldonwjw@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 <csdread@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.


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