Weldon Washburn wrote:
On 7/18/06, Volynets, Vera <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] On Behalf Of Egor Pasko
Sent: Saturday, July 15, 2006 9:37 AM
To: [email protected]
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: [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]
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
