2006/6/1, Weldon Washburn <[EMAIL PROTECTED]>:
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
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
