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 16:16:51 GMT
2006/6/1, Weldon Washburn <weldonwjw@gmail.com>:
> On 6/1/06, Ivan Volosyuk <ivan.volosyuk@gmail.com> wrote:
> > 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>:
> > > > 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.
> Yes.  This is a rough spot.  MMTK really wants a substituting write
> barrier that is written entirely in Java.  At least initially, I think

Oops. This complicates things much. I have realized that we can have
more problems. I didn't looked at MMTk yet so I didn't understand this
requirement. Now...

Invocation of Java code at write barrier means that it should be
GC-safe point. As the writting to slot operates with direct pointers
this code is not GC-safe. So existing VM and interpreter write
barriers are not ready for MMTk :(

> we should call the existing native code support for clone and
> arraycopy.  Else we end up rewritting the entire jvm in java.  For
> initial bring up, it should be OK to simply disallow GC during clone
> and arraycopy's memcpy() operation.

Note: this could be not enough depending on the algorithms used by
MMTk, but might work for some of them.

> >
> > >
> >> > 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
> > object_generic.cpp:object_clone()
> > The same code used here, instead of substituting write barrier we
> > write all the object data and (avoiding GC) call
> > write_barrier(object_with_slot_written_to).
>
> Agreed.  We are saying the same thing.
>
> >
> > >
> > > 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.
>
> I looked at 504.  All of this is starting to make sense.
>
> >
> > You can try to bring MMTk to work using interpreter mode. I have
> > validated the correctness of write barriers and they should work ok.
>
> I did not realize this.  What did you test interpreter write barriers with?

I have created per-slot mirror of heap. The write barrier did the
writting of value to the heap object's slot and the mirrored object's
slot too. I have used stop-the-world GC. Before each GC there was a
pass comparing all slots with their mirrors. After the GC mirror was
synchronized with the heap. Thus, I have found all missing write
barriers.

> > 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.
>
> Good point.  Please remind me when I get to that stage of development
> to ask harmony-dev if anyone has a tool for validating write barrier
> correctness.  I will also look at MMTK sources to see if any such
> facility exists.

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