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 design questions
Date Wed, 12 Jul 2006 08:13:52 GMT
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)
>> 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.
MetadataA and B were introduced to solve a problem in the JikesRVM opt 
compiler.  While I'm not sure of the details, they allow the compiler to 
preserve type information across the write barrier call.  Bottom line: 
they're there for the compiler: don't need 'em, pass zeros.
> mode
>> Can't we go without all the stuff and have only 2 args - an
>> object being written and the destination class/array/instance ? :-)
These parameters support different styles of barrier.  Some barriers 
remember objects which have been mutated, then scan the object during a 
minor GC; others remember the pointer itself, and avoid having to scan 
(potentially large) objects - hence the need for the src and slot 

The mode parameter could potentially allow the two strategies to 
coexist, by saving slots for address arrays (expensive to scan if big) 
and objects for scalars.  I don't think we do it, but it would be a 
shame to make it impossible.

> 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".
I expect this is probably the approach you're taking, but I would do the 
port by targeting the NoGC, MarkSweep, SemiSpace, CopyMS and GenMS 
collectors in that order - the write barrier isn't needed then until the 
very end.

> 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.
We also assume that the compiler will probably optimize all the 
parameters away or into registers, so the # parameters shouldn't be a 
performance issue.

-- Robin

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