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
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 <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


Mime
View raw message