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] adding write barriers to Jitrino.JET
Date Thu, 01 Jun 2006 14:47:21 GMT
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
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.
>
> >
>> > 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?

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


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