Weldon,
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
org.mmtk.utility.Constants.*WRITE_BARRIER
- 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 -
http://issues.apache.org/jira/browse/HARMONY-816
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 ?
p.s.
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:
http://issues.apache.org/jira/secure/attachment/12337096/magics.cpp.
This new magics.cpp replaces previous one completely (no need to
merge/whatever).
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?
--
Thanks,
Alex
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 <[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
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
