harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject Re: [Fwd: MMTk re-org & prelim release]
Date Mon, 17 Jul 2006 14:15:33 GMT

It looks like vmmagic Address.add() has been renamed Address.plus().
The MMTk port is very much blocked until jitrino.jet supports all the
unboxed vmmagic functions.  Alex --- can you fix this soon and post a
JIRA patch?  Below are the pointers to the latest MMTk code.

On 7/13/06, Steve Blackburn <Steve.Blackburn@anu.edu.au> wrote:
> Hi Weldon,
> Please let me know if you have any queries.  You should find everyhting
> you need inside the jar (as well as being able to run against it).  You
> should be able to slurp it into Eclipse and edit it there without any
> problems.
> I suggest you start by looking at src/org/mmtk/vm/*
> Then to see a concrete example, look at
> ext/vm/JikesRVM/com/ibm/JikesRVM/mm/mmtk/
> THis directory has concrete instances of the abstract classes in the
> previous directory.
> Cheers,
> --Steve
> ---------- Forwarded message ----------
> From: Steve Blackburn <Steve.Blackburn@anu.edu.au>
> To: jikesrvm-core@lists.sourceforge.net
> Date: Fri, 14 Jul 2006 00:48:53 +1000
> Subject: MMTk re-org & prelim release
> Hi,
> For those interested in the pending reorganization of MMTk, I have
> finished the re-org and created a jar and a patch against Jikes RVM.
> The plan is to commit this to the cvs head as soon as the 2.4.5 release
> has been made (as long as everyone is happy with it ;-).
> http://cs.anu.edu.au/~Steve.Blackburn/private/mmtk-20060714.jar
> http://cs.anu.edu.au/~Steve.Blackburn/private/mmtk-reorg.patch.gz
> The most significant change is in the way MMTk interfaces to the VM.  In
> essence it is now a lot cleaner and the interface is properly checked.
> If you don't care about MM<->VM interfaces, then that's all you need to
> know, probably.
> Previously we used stubs comprising classes with static methods. The JVM
> provided classes which aliased (replaced) these, and there was no
> consistency checking between the two.  We used static methods for
> performance reasons. We now define our requirements of the VM through a
> set of abstract classes in org.mmtk.vm.  The VM implementor is then
> obliged to create final subclasses of these with the appropriate
> functionality.   We lean on the opt compiler and static initialization
> to make sure we don't loose performance.
> The subclasses are accessed by MMTk by reflectively creating singleton
> instances of each class at build time (using the value of the system
> property: "mmtk.hostjvm"), and then invoking methods on these.  So for
> example, I have now put the Jikes RVM bindings in a new package called
> "com.ibm.JikesRVM.mm.mmtk" (previously they aliased "org.mmtk.vm").
> Jikes RVM's opt compiler is smart enough to realize these are run-time
> constant and inline etc.  I have done some fairly careful performance
> analysis and it seems to make no difference to performance.  I'll do
> some more between now and when we commit it. The magic to make this
> happen is mostly in org.mmtk.vm.VM.
> If anyone is interested or has feedback, I'm happy to discuss it further.
> Cheers,
> --Steve

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

View raw message