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: [drlvm/mmtk] jitrino.jet write barrier initial implementaion
Date Mon, 10 Jul 2006 12:41:24 GMT
Weldon,

I just commited http://issues.apache.org/jira/browse/HARMONY-816
into JIRA.

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 ?

Currently, I've made a presumption that there must be some
static method to get it.
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' ?
	A highest valid addres in heap ? Or simply ~(void*)0 ?
   - What's the diff between diff() and sub() ? diff()=='abs(sub())' ?
   - Word::one() - what's this ? (Object)1 ?
   - what is AddressArray::getBacking() ?
   - rshl, rshr, rsha - they shift, but what and how
	exactly they're shifting ?
   - what are exact values for mode argument in writeBarrier ?
	Currently, I'm simply using 0/1/2.

-- 
Thanks,
   Alex




Weldon Washburn wrote:
> Alex,
> Sorry for taking so long to answer your questions below.  Please see
> the response inline.
>    Weldon
> 
> On 6/27/06, Alex Astapchuk <alex.astapchuk@gmail.com> wrote:
>> AFAIR from the recent thread, to implement WB for MMTk support, I have
>> to emit calls of
>>
>>        org.mmtk.plan.PlanLocal.writeBarrier(
>>                ObjectReference src,
>>                Address slot, ObjectReference tgt,
>>                Offset metaDataA, int metaDataB, int mode)
>> on every PUTSTATIC/PUTFIELD/AASTORE.
>>
>> I can guess what 'src' is - this is the object being written, right ?
>> But could you please point me what all other args are ?
> 
> A quick description of what all the writeBarrier() fields are:
> 
> src
> Reference pointer to the object that's getting modified via
> putfied/putstatic/aastore
> 
> slot
> The machine address into which the new reference will be stored
> 
> tgt
> The reference pointer that will get written into the slot
> 
> metaDataA
> The difference between the machine address of the "slot" and "src"
> 
> metaDataB
> I think its intended to be used as some sort of an index into VM
> internal (class loader) array struct that holds info on which fields
> of a given object are ref ptrs.
> 
> mode
> Mode is either PUTASTATIC, PUTFIELD, AASTORE
> 
>> Can't we go without all the stuff and have only 2 args - an
>> object being written and the destination class/array/instance ? :-)
> 
> If we did this, ultimately we would end up making some ugly hacks on
> MMTK's writeBarrier().  I'd like to avoid this approach until a real
> compelling reason surfaces.
> 
> For initial bring up, the only write barrier GC I worry about is
> mmtk.plan.generational.  The generational GC only uses "slot" for the
> actual write barrier.  Since it is a substituting write barrier,
> writeBarrier() calls the code that is responsible for actually
> scribbling the ref ptr on the Java heap.  The code that scribbles on
> the heap is intended to be developed during MMTK port.  Most likely I
> will write this code.  The only parameters needed (I think) is "slot"
> and "tgt".
> 
> In other words, you can fill in a zero for src, metaDataA, metaDataB
> and mode for initial bring up.  But ultimately they have to have
> legitimate values to satisfy MMTK writeBarrier() interface.
> 
>>
>>
>> -- 
>> Thanks,
>>   Alex
>>
>>
> 
> 




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