On 6/1/06, Ivan Volosyuk <[EMAIL PROTECTED]> wrote:
2006/6/1, Weldon Washburn <[EMAIL PROTECTED]>:
> On 5/31/06, Ivan Volosyuk <[EMAIL PROTECTED]> wrote:
> > 2006/6/1, Rana Dasgupta <[EMAIL PROTECTED]>:
> > 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Weldon Washburn
Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
