harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivan Volosyuk" <ivan.volos...@gmail.com>
Subject Re: [DRLVM][GC] high-level design proposal for GCV5
Date Fri, 25 Aug 2006 08:50:46 GMT
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 <xiaofeng.li@gmail.com> 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 <ivan.volosyuk@gmail.com> 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: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> 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
>
>


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


Mime
View raw message