You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by "Vera Volynets (JIRA)" <ji...@apache.org> on 2006/07/14 19:07:21 UTC
[jira] Created: (HARMONY-881) DRLVM GC heap verification
infrastructure
DRLVM GC heap verification infrastructure
--------------------------------------------
Key: HARMONY-881
URL: http://issues.apache.org/jira/browse/HARMONY-881
Project: Harmony
Issue Type: New Feature
Components: Contributions
Reporter: Vera Volynets
************* 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.
To apply patch:
patch -p1 < 000*.txt
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (HARMONY-881) DRLVM GC heap verification
infrastructure
Posted by "Vera Volynets (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HARMONY-881?page=all ]
Vera Volynets updated HARMONY-881:
----------------------------------
Attachment: 0002-Checks-correctness-of-gc-work.txt
This is GC heap verification infrastructure.
It verifys that the structure of object reference graph stays
exactly the same during collection. Therefore
number of strongly reachable live objects and
live bytes before and after GC should stay
unchanged.
Run vm with option:
-Dvm.verify.gc=true in command line.
---
d9d2f53581754029e051b91bd6bbfdecf10e34fb
vm/vmcore/include/environment.h | 3
vm/vmcore/include/gc_debug.h | 24 +
vm/vmcore/src/gc/gc_debug.cpp | 417 +++++++++++++++++++++
vm/vmcore/src/gc/stop_the_world_root_set_enum.cpp | 12 +
vm/vmcore/src/init/vm.cpp | 3
vm/vmcore/src/init/vm_main.cpp | 7
6 files changed, 462 insertions(+), 4 deletions(-)
> DRLVM GC heap verification infrastructure
> -----------------------------------------
>
> Key: HARMONY-881
> URL: http://issues.apache.org/jira/browse/HARMONY-881
> Project: Harmony
> Issue Type: New Feature
> Components: Contributions
> Reporter: Vera Volynets
> Attachments: 0001-Add-function-to-gc-interface.txt, 0002-Checks-correctness-of-gc-work.txt
>
>
> ************* 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.
> To apply patch:
> patch -p1 < 000*.txt
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (HARMONY-881) DRLVM GC heap verification
infrastructure
Posted by "Vera Volynets (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HARMONY-881?page=all ]
Vera Volynets updated HARMONY-881:
----------------------------------
Attachment: 0001-Add-function-to-gc-interface.txt
Add funtion gc_add_finalizable_root_set_entry() to gc interface.
It's needed for separate enumeration
of finalizable roots in gc_debug mode.
Because some finalizable objects can be unreachable
after GC gc_debug won't work properly.
So it counts number of strongly live objects
and finalizable ones separatly.
---
773b7cb7e8be42f04afcfdcbad63c0311e428368
vm/gc/src/gc_for_vm.cpp | 13 +++++++++++++
vm/include/jit_import_rt.h | 3 +++
vm/include/open/gc.h | 5 +++++
vm/vmcore/src/gc/dll_gc.cpp | 2 ++
vm/vmcore/src/gc/root_set_enum_common.cpp | 21 +++++++++++++++++++++
vm/vmcore/src/init/finalize.cpp | 2 +-
6 files changed, 45 insertions(+), 1 deletions(-)
> DRLVM GC heap verification infrastructure
> -----------------------------------------
>
> Key: HARMONY-881
> URL: http://issues.apache.org/jira/browse/HARMONY-881
> Project: Harmony
> Issue Type: New Feature
> Components: Contributions
> Reporter: Vera Volynets
> Attachments: 0001-Add-function-to-gc-interface.txt
>
>
> ************* 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.
> To apply patch:
> patch -p1 < 000*.txt
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (HARMONY-881) DRLVM GC heap verification
infrastructure
Posted by "Vera Volynets (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HARMONY-881?page=all ]
Vera Volynets updated HARMONY-881:
----------------------------------
Attachment: 0003-Checks-correctness-of-write-barriers-work.txt
See comment to this patch above.
> DRLVM GC heap verification infrastructure
> -----------------------------------------
>
> Key: HARMONY-881
> URL: http://issues.apache.org/jira/browse/HARMONY-881
> Project: Harmony
> Issue Type: New Feature
> Components: Contributions
> Reporter: Vera Volynets
> Attachments: 0001-Add-function-to-gc-interface.txt, 0002-Checks-correctness-of-gc-work.txt, 0003-Checks-correctness-of-write-barriers-work.txt
>
>
> ************* 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.
> To apply patch:
> patch -p1 < 000*.txt
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (HARMONY-881) DRLVM GC heap verification
infrastructure
Posted by "Salikh Zakirov (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HARMONY-881?page=comments#action_12432154 ]
Salikh Zakirov commented on HARMONY-881:
----------------------------------------
The patch 0001-Add-function-to-gc-interface.txt introduces new GC interface function without a good reason to do so.
Since the verificatio infrastructure is implemented inside the VM, the finalizable queue can be accessed wihtout introducing
new GC-VM interface function.
I think the patch needs to be reworked to be accepted.
> DRLVM GC heap verification infrastructure
> -----------------------------------------
>
> Key: HARMONY-881
> URL: http://issues.apache.org/jira/browse/HARMONY-881
> Project: Harmony
> Issue Type: New Feature
> Components: Contributions
> Reporter: Vera Volynets
> Attachments: 0001-Add-function-to-gc-interface.txt, 0002-Checks-correctness-of-gc-work.txt, 0003-Checks-correctness-of-write-barriers-work.txt
>
>
> ************* 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.
> To apply patch:
> patch -p1 < 000*.txt
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (HARMONY-881) DRLVM GC heap verification
infrastructure
Posted by "Vera Volynets (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HARMONY-881?page=comments#action_12427500 ]
Vera Volynets commented on HARMONY-881:
---------------------------------------
I would like to introduce you a small feature to GC heap verification infrastructure.
It is also hijacked into GC-VM interface.
After gc initialization functions concerning write barriers are hijacked and all write operations are recorded in array which I called heap mirror.
During first heap traversal content of heap mirror is compared with gc heap. So the right usage of write barriers is verified.
At this moment my code triggers verification failure, but I couldn't find out what causes this failure. I observed verification failure on tests stress.Finalizer and stress.Mix. The reason of failure can be either in my code or in vm, because to this very day only stop-the-world collector was used, so implementation and usage of write barriers were not properly verified. I rely on you participation to find the reason of failure.
To use this patch patches "Enable GC write barriers in DRLVM" HARMONY-504 and two patches from "DRLVM GC heap verification infrastructure" HARMONY-881 should be applied first.
Also this feature works only with interpreter enabled:
-Dvm.use_interpreter=true.
To turn on this feature:
-Dvm.gc.verify.wb=true.
See attached file: 0003-Checks correctness of write barriers work.txt
> DRLVM GC heap verification infrastructure
> -----------------------------------------
>
> Key: HARMONY-881
> URL: http://issues.apache.org/jira/browse/HARMONY-881
> Project: Harmony
> Issue Type: New Feature
> Components: Contributions
> Reporter: Vera Volynets
> Attachments: 0001-Add-function-to-gc-interface.txt, 0002-Checks-correctness-of-gc-work.txt
>
>
> ************* 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.
> To apply patch:
> patch -p1 < 000*.txt
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira