harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivan Volosyuk" <ivan.volos...@gmail.com>
Subject Re: [DRLVM] adding write barriers to Jitrino.JET
Date Thu, 01 Jun 2006 11:20:15 GMT
2006/6/1, Weldon Washburn <weldonwjw@gmail.com>:
> On 5/31/06, Ivan Volosyuk <ivan.volosyuk@gmail.com> wrote:
> > 2006/6/1, Rana Dasgupta <rdasgupt@gmail.com>:
> > >
> > >   It may be worth considering if we want JET to just call the barrier
> > > functionality( with from/to/and slot locations )and the barrier helper
> > > actually do everything ... including generating the store. May be
> > > unconventional, but more modular.
> >
> > Actually, this is the best way to do that. Thus we allow much
> > flexibility for the implementation of write barriers. I have found a
> > few exceptions from this rule in DRLVM VM code. It is the
> > implementation of atomic exchange of object field value, arraycopy and
> > object_clone. We should think about this to.
> hmm.... I suspect the fundamental problem is that from the GC's
> perspective if a write to a heap location that contains a reference
> has occurred, the GC must also see the write barrier.  Interestingly
> it is OK if the GC sees a write barrier without the corresponding
> field changing value.  In this case, the GC will scan a field that
> simply has not changed.  A small waste of time but still correct.
> From what I recall, there are two ways to solve the atomic
> (write_object, write_barrier) tuple problem.  Either use an
> instruction like a DCAS (double compare and swap) or  guarantee that a
> GC can not happen between the move to object field and write barrier
> code.  The last time I looked, ia32 does not have DCAS instruction.
> In addition, each write of a reference to the Java heap would mean the
> HW issues an atomic operation.  This could get expensive. Thus its not
> worthwhile discussing this approach further.  An approach that I used
> in ORP was to guarantee that a thread can not be suspended for a GC
> between the write_object and write_barrier pair.  The details are
> longer than this email will allow.

Agree. Avoiding GC between write_object and write_barrier is enough.

> > Let me give you a few
> > details.
> >
> > We have in DRLVM implementation the atomic exchange of value stored in
> > object field. It is required IMO for the j.u.atomics package. It
> > require some additonal function in GC interface to do atomic swap of
> > the value with write barrier.
> I don't get it. Do you really mean to use atomic swap in the write
> barrier?  Why?  Where in harmony drlvm do I find this code?

I have written this thinking from the perspective that we leave only
substituting write barrier mentioned by Rana. Here is the difficult
place to use this approach. For this case in VM currently use
gc_write_barrier(object_with_slot_written_to) just after the
object_write operation.

> >
> > Object clone and System.arraycopy write/modify whole object with
> > number of references in it. For the performance its currently use
> > special write barrier function which simply gives the object reference
> > saying: the whole object is changed - do something.
> >We can leave the
> > variant of write barrier or just remove it and change these functions
> > respectivly.
> This is really confusing.   I am looking at
> optimize_ia32.cpp:gen_native_arraycopy_fastpath() and
> object_generic.cpp:object_clone() from JIRA Harmony-438.  Can you tell
> me which lines of code contain the "special write barrier"?

I was talking about vm_arrays.cpp:array_copy() and
The same code used here, instead of substituting write barrier we
write all the object data and (avoiding GC) call

> As far as I understand, I should use Harmony-438 as the base to add
> the write barrier code.  Is this correct?

As I mentioned before, you can use patch from
http://issues.apache.org/jira/browse/HARMONY-504. It contains changes
in VM and interpreter code adding missing write barriers there.

You can try to bring MMTk to work using interpreter mode. I have
validated the correctness of write barriers and they should work ok.

If you are going to make jitrino.jet changes, it is worth to
find/implement a tool which will validate the correctness of this new
write barriers implementation, otherwise you may end up spending great
amount of time investigating random crashes.
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