harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject Re: [drlvm/mmtk] jitrino.jet write barrier design questions
Date Mon, 03 Jul 2006 20:48:41 GMT
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
>
>


-- 
Weldon Washburn
Intel Middleware Products Division

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