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: local policy)
Date: Tue, 05 Sep 2006 18:17:09 +1000
From: Robin Garner <robin.garner@anu.edu.au>
Subject: Re: [DRLVM] GC heap verification infrastructure
In-reply-to: <4dd1f3f00607180807u5c958af1w9086355a56c61540@mail.gmail.com>
To: harmony-dev@incubator.apache.org
Message-id: <44FD3285.8030000@anu.edu.au>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
References: <2A786EB15713B544AB79607529273B04062B53@mssmsx411>
 <4dd1f3f00607180807u5c958af1w9086355a56c61540@mail.gmail.com>
User-Agent: Thunderbird 1.5.0.5 (X11/20060728)

Weldon Washburn wrote:
> On 7/18/06, Volynets, Vera <vera.volynets@intel.com> wrote:
>> Hi,
>> I didn't find any bugs in gc_v4 at the moment,
> 
> Vera, its good to know the verifier found zero bugs in GCV4!
> 
>> but this feature is really very useful especially if
>> you modify gc_v4 or design a new gc. Of course, it needs to
>> be improved and developed.
> 
> This brings up a good point.  Harmony-dev needs to discuss the roadmap
> for DRLVM GC.  I will start a discussion thread shortly.
> 
>>
>> Also I'm going to add feature to verify write barriers work.
> 
> Some comments.
> 
> 1)
> There is no DRLVM GC that uses a write barrier currently.  Assuming
> you have a write barrier verifier, how will you know it works?
> 
> 2)
> I would like to see the design of the write barrier verifier discussed
> on harmony-dev mailing list before implementation is started.  I am
> interested in using the proposed write verifier on DRLVM/MMTk.

The first method to occur to me (and I'm afraid this is shamelessly 
MMTk-centric :) is to write a write-barrier validating plan:

- Mutator runs, using write barrier to populate the REMSET
- Collector performs a full-heap collection (a-la IGNORE_REMSETS), 
however, whenever an old-to-new pointer is encountered, you check 
whether the pointer was recorded in the REMSET.
- Ditto for roots that point into the nursery.

It would need to take care not to flag references from objects promoted 
from the nursery earlier in this collection, but this shouldn't be too 
hard to arrange.

This should also be quite easy to build entirely within MMTk (sorry GCV5 
guys :)

Another (better) approach would be to write a REMSET sanity checker. 
When enabled by a command-line switch it would inject an extra phase 
into the GC phase list (like the existing sanity checker does), and 
before a nursery collection it would:

- do a full-heap trace, using private side metadata
- Record all references that point into the nursery
- when done, check this against the remset and report discrepancies.

The remset should contain a superset of the references that this sanity 
checker finds.  There's no real reason this couldn't live in MMTk 
permanently.

>> The same way as in GC heap verification I use idea to
>> hijack interface function concerning write barriers.
>>
>> This patch will be sent a bit later.
>>
>> Pleased to hear from you, Vera :)!
>>
>> -----Original Message-----
>> From: news [mailto:news@sea.gmane.org] On Behalf Of Egor Pasko
>> Sent: Saturday, July 15, 2006 9:37 AM
>> To: harmony-dev@incubator.apache.org
>> Subject: Re: [DRLVM] GC heap verification infrastructure
>>
>> On the 0x1A6 day of Apache Harmony Vera Volynets wrote:
>> > *************   GC heap verification infrastructure   ***************
>> > Hi,
>> > I have been working on implementing GC heap verification
>> infrastructure
>> > for Stop-The-World GC in DRLVM.
>> > This infrastructure is intended be used with any stop-the-world GC
>> > implementation, conforming to the GC-VM interface (described in gc.h
>> and
>> > vm_gc.h), with only a minor GC-VM interface change.
>> > It works on Windows and Linux ia32 platforms.
>>
>> cool feature! did you find any bugs in DRLVM while testing?
>> do you have plans/ideas for future development of the tool?
>>
>> > [...]
>> >
>> > *Patch contents*
>> > This is an individual contribution, and it was prepared according to
>> the
>> > requirements of Apache cleanroom process; the size of two files all in
>> > all is about 30kb (161 and 585 lines).
>> > -Patch Add-function-to-gc-interface.txt
>>
>> oh, I found it! HARMONY-881
>>
>> -- 
>> Egor Pasko, Intel Managed Runtime 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
>>
>> ---------------------------------------------------------------------
>> 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