harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rana Dasgupta" <rdasg...@gmail.com>
Subject Re: [DRLVM] adding write barriers to Jitrino.JET
Date Fri, 02 Jun 2006 01:39:22 GMT
Hi Weldon/Ivan,
   This has been a long thread/dialog. I am going to try and summarize where
we stand at this stage ( for my own understanding ) and also to invite
comments on implementation direction and suggestions from knowledgeable VM
developers on the list. Please fill in if I miss or misstate something :-) I
have not seen the MMTk implementation.

1. The DRLVM submission has two jits jitrino.jet and jitrino.opt. The first
one is a simpler, fast baseline jit. Weldon is proposing to implement the
barrier functionality here first. The focus is initially not performance,
but to get MMTk up and running with DRLVM.
2. For purposes of flexibility, ultimately inlinability, and since MMTk
needs it, the barrier will be a substituting write barrier. This means that
.Jet will call the barrier helper( to be defined ) and the barrier
functionality will do the store + barrier update + whatever special
functionality needed.
3. Read barriers are a future project, though MMTk needs it.
4. The http://issues.apache.org/jira/browse/HARMONY-504 patch has the
corresponding VM and support for WB. In this patch, the interpreter also
supports write barriers. So in theory, one should be able to bring up MMTk
in interpreter mode even before modifying .Jet?
5. There area a few places in DRLVM code where the substituting barrier
could be a problem a) an atomic object slot update which does a test and set
followed by a conventional barrier update. This probably needs its own
interface entry and will need to be special cased. Ultimately MMTk will need
to provide some supporting functionality for this b) arraycopy and object
clone where a lot of updates happen together and then a object level barrier
is invoked. This code could just be left alone and GC suspended during the
updates for now.
6. Weldon made a late comment that MMTk needs the WB to be in Java. If true,
this is a major requirement and I did not understand the resolution if any.



Thanks,
Rana




On 6/1/06, Ivan Volosyuk <ivan.volosyuk@gmail.com> wrote:
>
> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message