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
Sorry for taking so long to answer your questions below.  Please see
the response inline.

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:

Reference pointer to the object that's getting modified via

The machine address into which the new reference will be stored

The reference pointer that will get written into the slot

The difference between the machine address of the "slot" and "src"

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.


> 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

View raw message