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 <[EMAIL PROTECTED]> wrote:
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]
