[jira] Commented: (HARMONY-5843) [drlvm][gc] class unloading is unstable

["Chunrong Lai (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/HARMONY-5843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12618068#action_12618068 ] 

Chunrong Lai commented on HARMONY-5843:
---------------------------------------


   I'd like to add more comments for this patch.
   I see that the reported unstableness raises from the heap iteration process. It is noted that GC_Gen needs to parse the vtable of every objects to iterate heap. As reported the iteration process may crash if class of some objects are unloaded thus the vtables become invalid.
   What the patch do are (1) When GC decide to keep a dead object in heap (it should not be a common case), which means that the object is possibly iterated and the class is possibly unloaded in future, the vtable is linked to next valid object in heap. (2) Update the heap iteration process to adapt the change. The modifications impact the functions of next_marked_obj_in_block and gc_gen_iterate_heap.

> [drlvm][gc] class unloading is unstable
> ---------------------------------------
>
>                 Key: HARMONY-5843
>                 URL: https://issues.apache.org/jira/browse/HARMONY-5843
>             Project: Harmony
>          Issue Type: Bug
>          Components: DRLVM
>            Reporter: Alexey Varlamov
>            Assignee: Chunrong Lai
>         Attachments: H5843.fixed.patch
>
>
> On class-unloading scenarious, DRLVM easily hits a bunch of asserts in gc_gen. Most typical asserts are:
>     [junit] Assertion failed: obj && obj->vt_raw, file c:\users\avarlamo\trunk\working_vm\vm\gc_gen\src\common\gc_for_class.h, line 207
>     [junit] Assertion failed: address_belongs_to_gc_heap(addr, gc), file c:\users\avarlamo\trunk\working_vm\vm\gc_gen\src\thread\../gen/gen.h, line 152
>     [junit] Assertion failed: vm_object_size(obj) != 0, file c:\users\avarlamo\trunk\working_vm\vm\gc_gen\src\common\gc_block.h, line 146
> These asserts fire intermittently, may be reproduced in any mode including interpreter and on any platform (yet on different machines a particular assert happens more often than others).
> To reproduce, run lazy.test suite:
> working_vm$ ant lazy.test
> For convenience, there is standalone launcher org.apache.harmony.vm.test.lazyresolution.StressTest which can vary stress load, e.g.:
> working_vm$ cd build\windows_x86_msvc_debug\tests\lazy.tests\classes
> classes$ java -cp .;junit.jar -Dlazy.test.iterations=100 -Dlazy.test.threads=10 org.apache.harmony.vm.test.lazyresolution.StressTest

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.