harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Astapchuk <alex.astapc...@gmail.com>
Subject Re: [Fwd: MMTk re-org & prelim release]
Date Tue, 18 Jul 2006 12:14:49 GMT

I've updated the magics.cpp to reflect the changes in MMTk:

- add/sub replaced with plus/minus
- fixed constants passed to MMTk's WB code wrt
- Stub implementation of atomic attempt() (always succeeds currently)
- Stub (no-op) implementation for prepare*() and prefetch()
- changed rsha/rshl impl wrt Robin Garner's clarification

I attached new magics.cpp the the same JIRA issue -
I had no chance to test new functionality properly.

I believe there must be a test suite for at least unboxed/*
things. Does anybody knows if it really exists ?

I though new file with the same name replaces/obsoletes previous one,
but it does not. So, currently there are 2 magics.cpp in the JIRA issue.
Please don't be confused by it. The proper one is the latest:
This new magics.cpp replaces previous one completely (no need to

Btw, I did not find a way to remove previos file. Did I overlooked
something ?
I don't think creating new JIRAs is a good solution, but I also don't
want to overflow the single issue with several files with the same name
(I expect more magics.cpp to come).
What is the best strategy to manage it?


Weldon Washburn wrote:
> 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 <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

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