Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of ivan.volosyuk@gmail.com
 designates 64.233.166.180 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=nTlVpfo/f4LON1E8gAbNe4DrUoUofje1ltflBZllsc9oTECvskjMtLPFp+eQZsZEZ3wvCAcsMmEX8AmOBjmXt9xbXYsCAh1qxKXKtknC9fEN2RGvA4Er2XTzdZrpzSMxGrBUDLkH0dEC9ZM08gkmtfwWIt3yeoq1WocJKm5jzvc=
Message-ID: <12385bbd0608250150q2f187085v213f2a190b252c20@mail.gmail.com>
Date: Fri, 25 Aug 2006 12:50:46 +0400
From: "Ivan Volosyuk" <ivan.volosyuk@gmail.com>
To: harmony-dev@incubator.apache.org
Subject: Re: [DRLVM][GC] high-level design proposal for GCV5
In-Reply-To: <9623c9a50608241908w5ccea02ey1b2bb76c8d4659d1@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <9623c9a50608220046l34444a50v5197e8c96825c73a@mail.gmail.com>
	 <4dd1f3f00608231344t60b6bc73u13bee187c39aea49@mail.gmail.com>
	 <9623c9a50608232021pd7d976ay7010390856f43179@mail.gmail.com>
	 <12385bbd0608240654w314ea2faw3a705ecac7a8886e@mail.gmail.com>
	 <9623c9a50608241908w5ccea02ey1b2bb76c8d4659d1@mail.gmail.com>

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