I just checked the IterateOverHeap/IterateInstances issue. I found the
problem is not in GCv5 but in the tag setting of the JVMTI environment.
In my experiments there is assertion failure in
assert(global_ti_env->tags) at vm_iterate_object(), which probably means no
tag setting before gc_iterate_heap().
GCv4.1 has not this problem because it initializes the
jvmti_heap_iteration as false, which means the heap is not iterated, so no
vm_iterate_ovject() is called, even if JVMTI environment askes it to do.
Instead I did not see GCv5 has internal problem in gc_iterate_heap().
So I am also looking for your suggestion for below options (1) Set
jvmti_heap_iteration of GCv5 with false as GCv4.1. (2) Discard the assertion
in vm_iterate_object. (3) Rewrite the test case to set tag before
gc_iterate_heap().
-regards,
chunrong
On 5/8/07, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
They might be caused by recent switch of the GC to GCv5. Will check,
thanks.
xiaofeng
On 5/7/07, Petrashkova, Vera Y <[EMAIL PROTECTED]> wrote:
> 3 tests from DRLVM Validation test suite
> (http://issues.apache.org/jira/browse/HARMONY-3206) failed on DRLVM
> r535615 Windows2003 ia32 while passed since r531398.
>
>
>
> 1) The following jvmti tests
>
>
> vm.jvmti.funcs.IterateInstances.IterateInstances0101.IterateInstances010
> 1
>
>
> vm.jvmti.funcs.IterateOverHeap.IterateOverHeap0101.IterateOverHeap0101
>
>
>
> failed because VM crashes on jvmti methods
>
>
>
> IterateOverHeap(jvmtiEnv* env,
> jvmtiHeapObjectFilter object_filter,
> jvmtiHeapObjectCallback heap_object_callback,
>
> void* user_data)
>
> IterateOverInstancesOfClass(jvmtiEnv* env,
> jclass klass,
> jvmtiHeapObjectFilter object_filter,
> jvmtiHeapObjectCallback heap_object_callback,
>
> void* user_data)
>
>
>
> when parameter object_filter equals to JVMTI_HEAP_OBJECT_UNTAGGED or
> JVMTI_HEAP_OBJECT_EITHER
>
>
>
> VM works correctly when object_filter equals to
> JVMTI_HEAP_OBJECT_TAGGED.
>
>
>
> 2) VM also crashes on the following test which creates large array
>
>
> vm.jvms.instructions.reftypes.anewarray.anewarray09.anewarray0901.anewar
> ray0901
>
>
>
> It is occurred on Windows 2003 but this test passes on Windows XP.
>
>
>
> These failures may be intermittent because the listed tests failed on
> DRLVM r531398 but they passed on the next builds till r535615.
>
>
>
>
>
>
>
> Thank you,
>
> Vera Petrashkova
>
>
>
>
>
>
--
http://xiao-feng.blogspot.com
