All, 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
