Yes, I have experimented with per-slot verification of write barrier.
The idea was the following: each word in java heap has external mirror record. After garbage collection all mirror records are synchronized with the heap. Each write barrier updates mirror record with corresponding data. Before next garbage collection there is a trace for all reachable objects in heap which validates that each slot contains the same data as the mirror. The idea is quite simple. Even that, it helped my find number of places in VM code which have updated slots in heap without call to write barrier. The results of the work are in HARMONY-504. The scheme has one impotant limitation. When several threads write to single slot, this verifier may report false-positive result of missing write barrier. But, I didn't see such situtations in any workloads I have tested it with. -- Regards, Ivan On 8/25/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
Ivan, there is no disagreement on the importance of those verifications (or validations) for Harmony GC. :-) What I was saying is we need more thinking on the design than the rough idea, such as when, how, what, etc. Have you any good idea on the write barrier verfication design? Thanks, -xiaofeng On 8/24/06, Ivan Volosyuk <[EMAIL PROTECTED]> wrote: > > > It might also make sense to design in a write barrier verifier. The > > > concept is to verify that all the old-to-young pointers are properly > > > handled. One way of doing this is to force a full heap mark. Then > > > compare the full heap mark's old-to-young pointers to what the write > > > barrier mechanism derived. > > > > This needs more thinking. The old-to-yound pointers got in a full-heap > > marking have only live ones. But I think the idea to have some write > > barrier verifier is interesting, e..g, the rememebered set has to be a > > superset of live old-to-yound pointers. > > IMHO, write barrier verifier is a _must_ to have feature for us. The > same applies to full heap tracing-validation. As VM and JIT code are > subject of changes, it should be the way to isolate bugs introduced by > GC and the ones coming from VM/JIT. > -- > Ivan > > > > > Thanks, > > xiaofeng > > --------------------------------------------------------------------- > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- 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]
