SAP reported TestHeapDump.java test failures on Windows.

Stack: [0x000000f766c00000,0x000000f766d00000]
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [jvm.dll+0x9ff771] os::platform_print_native_stack+0xf1 (os_windows_x86.cpp:369)
V [jvm.dll+0xc90fbb] VMError::report+0xf0b (vmerror.cpp:725)
V [jvm.dll+0xc9286e] VMError::report_and_die+0x8ae (vmerror.cpp:1533)
V [jvm.dll+0xc92f64] VMError::report_and_die+0x64 (vmerror.cpp:1317)
V [jvm.dll+0x42aa62] report_vm_error+0x102 (debug.cpp:264)
V [jvm.dll+0xb767c3] StringDedupTable::gc_epilogue+0x83 (stringdeduptable.cpp:547)
V [jvm.dll+0xb0d663] ShenandoahHeap::object_iterate+0x3d3 (shenandoahheap.cpp:1330)
V [jvm.dll+0x81efd5] VM_HeapIterateOperation::doit+0x55 (jvmtitagmap.cpp:1285)
V [jvm.dll+0xc93fde] VM_Operation::evaluate+0xbe (vmoperations.cpp:68)
V [jvm.dll+0xc99191] VMThread::evaluate_operation+0xa1 (vmthread.cpp:375)
V [jvm.dll+0xc99d90] VMThread::loop+0x5e0 (vmthread.cpp:522)
V [jvm.dll+0xc9a3f8] VMThread::run+0xd8 (vmthread.cpp:278)
V [jvm.dll+0xc2ac12] Thread::call_run+0x192 (thread.cpp:404)
V [jvm.dll+0x9fdf3e] thread_native_entry+0x10e (os_windows.cpp:465)
C [ucrtbase.dll+0x1f4a0]
C [KERNEL32.DLL+0x84d4]
C [ntdll.dll+0x6e8b1]

That is due to Shenandoah used parallel version of string dedup oops_do() implementation, which requires resetting string dedup table's claimed index.

If there is concurrent string dedup cleaning task in progress, bad thing happens.

Solution: use single-threaded version (oops_do_slow()) for heap iteration and don't call StringDedup::gc_prologue()/gc_epilogue()