Re: [DRLVM] GC heap verification infrastructure
+1 from me. 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. Well, the checker can be a layer between VM and GC. In C variant of write barriers it just inject some code before actual GC's write barrier which does mirroring of slot. When doing the full-heap trace it can compare slots and its mirrors (even not possessing information about organization of heap, e.g nurseries). -- Ivan - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DRLVM] GC heap verification infrastructure
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: 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: [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]
Re: Re: [DRLVM] GC heap verification infrastructure
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 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: 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: [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] -- Weldon Washburn 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]
RE: Re: [DRLVM] GC heap verification infrastructure
Hi, I didn't find any bugs in gc_v4 at the moment, 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. Also I'm going to add feature to verify write barriers work. 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: 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: [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]
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]
[DRLVM] GC heap verification infrastructure
* 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. *Description* GC heap verification infrastructure is a small module which is hijacked into GC-VM interface. The main idea is to substitute GC interface function so that necessary information can be easily collected. Everybody who is interested in GC development and debugging is invited to try it, modify files and add their own functionality. At this moment GC heap verification infrastructure verifies that the structure of object reference graph stays exactly the same during collection. Therefore, the number of strongly reachable live objects and live bytes before and after GC should stay unchanged. The verification is performed in two phases: 1) On the start of Stop-The-World phase, all enumerated roots to GC by VM are cached by GC heap verification infrastructure and heap is traversed, constructing heap "fingerprint", recording the order of the objects and counting their number and size. 2) After actual garbage collection is complete, before resuming user threads, the heap is traced once again and the heap structure is verified. *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 It adds function gc_add_finalizable_root_set_entry() for separate counting of finalizable objects because the GC may not preserve ordering of finalizable objects, and thus the heap structure can be changed. -Patch Checks-correctness-of-gc-work.txt The heart of this patch is file gc_debug.cpp. The tracing of heap starts with debug_gc_trace_heap() function. *Users guide* The debugging mode is off by default, and has no impact on the GC performance.. - To turn on GC Debug infrastructure use VM with -Dvm.verify.gc=true option in command line. - To see debug information build VM in debug mode, BUILD_CFG=debug, and use logger in usual way. When enabled, the verification heap trace takes quite a bit of time (two times for each collection: before and after actual collection), GC pauses increase by 1.5-2 times (from 1406ms to 2515ms) when running Eclipse on DRLVM built in debug configuration. -- Vera Volynets, 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]
