harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robin Garner <robin.gar...@anu.edu.au>
Subject Re: [drlvm/mmtk] jitrino.jet write barrier initial implementaion
Date Tue, 11 Jul 2006 06:30:55 GMT
Weldon Washburn wrote:
> On 7/10/06, Alex Astapchuk <alex.astapchuk@gmail.com> wrote:
>> Weldon,
>> I just commited http://issues.apache.org/jira/browse/HARMONY-816
>> into JIRA.
> Thanks.  I will look at it today.
>> It contains the changes for Jitrino.JET:
>> - magics support for MMTk
>> - write barriers for Java for MMTk
>> - a simple test to check the things are alive
>> I also have few questions on unboxed package and some MMTk
>> internals, that I was unable to resolve myself (I used javadocs
>> from http://jikesrvm.sourceforge.net/api/) and I would
>> appreciate a help on resolving them.
>> The main obstacle is that writeBarrier method in PlanLocal is
>> instance method.
>> I failed to find a way how to get the proper instance during
>> runtime - and this is the first question - how to get the
>> proper instance of PlanLocal ?
> Yes.  We will need to add APIs for the jit to get the ref ptrs to a
> few MMTk java objects.  My guess is that MMTk can allocate these
> objects in "immortal space" which is never moved, never collected thus
> the ref pointer is always valid.
The latest CVS head for MMTk clarifies/complicates this even more:)

Steve has refactored the PlanLocal into a 'MutatorContext' and a 
'CollectorContext' object.  The Mutator Context is a per-thread data 
structure, and the collector context is per-GC-thread (MMTk collectors 
are parallel).
>> Currently, I've made a presumption that there must be some
>> static method to get it.
> We need to discuss the approaches.  The API could be a static java
> method but this requires the JIT to call out to java code while
> jitting which might not be a good idea.  Another approach is to use
> the existing class loader API to return the address of a java static
> variable.  Its a proven/tested existing interface.  Thoughts?
What about a pointer off the per-thread data structure ?
>> I used a simple fake stub to test the implementation
>> (it's in PlanLocal.java attached to the JIRA).
>> Also, there are few questions on unboxed package:
>>   - Address::max() - what is 'maximul allowable Address' ?
> I think its 2**32 or 2**32-1 or something like that.
>>        A highest valid addres in heap ? Or simply ~(void*)0 ?
> The above seems reasonable.  The rest of your questions I will think
> about and get back to you.
Address::min() should be 0.
>>   - What's the diff between diff() and sub() ? diff()=='abs(sub())' ?
(sub has actually been replaced by minus in the past few weeks)

Diff() returns an Offset (a signed quantity) that represents the 
distance between two addresses.  sub() (or minus() now) subtracts an 
offset from an address returning an address.  The difference is in the 
types they take and return, and interpretation of arguments as signed or 
>>   - Word::one() - what's this ? (Object)1 ?
Almost (modulo types).  It's the value 1, as type Word.
>>   - what is AddressArray::getBacking() ?
No idea.  Current MMTk CVS head doesn't have it.
>>   - rshl, rshr, rsha - they shift, but what and how
>>        exactly they're shifting ?
Right-shift arithmetic (ie with sign extension) and right-shift logical 
(no sign extend).  Never heard of rshr.
>>   - what are exact values for mode argument in writeBarrier ?
>>        Currently, I'm simply using 0/1/2.
these are the *_BARRIER constants in org.mmtk.utility.Constants.


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