RFR: 8274196: Crashes in VM_HeapDumper::work after JDK-8252842 [v4]

Per Liden pliden at openjdk.java.net
Mon Sep 27 13:10:07 UTC 2021


On Mon, 27 Sep 2021 12:02:53 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> The root cause for crash in ZGC is that the JNIHandles are processed before object iteration. And ZGC would update the JNIHandles at object iteration with read barrier. So the crash is cause by accessing the invalid address which can be dummy info after zgc, and hence crash.
>> 
>> The lock rank issue can be fixed because the related mutexes are acquired in safepoint. so the safepoint_check_required could be safepoint_check_always.
>> 
>> The Epsilon issue is caused by wrong _num_dumper_thread calculated when the gang==NULL.
>
> Lin Zang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove redundant empty line

src/hotspot/share/services/heapDumper.cpp line 1601:

> 1599: void JNILocalsDumper::do_oop(oop* obj_p) {
> 1600:   // ignore null handles
> 1601:   oop o = NativeAccess<AS_NO_KEEPALIVE>::oop_load(obj_p);

The JNI Local roots do not need a load barrier, only JNI Global roots need that. The JNI Local roots are processed on safepoint entry as part of the "thread head" (via `ZStackWatermark::ZStackWatermark::start_processing_impl()` -> `Thread::oops_do_no_frames()`), so once you are in `VM_HeapDumper::do_thread()` the JNI Local roots have already passed a load barrier.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5681


More information about the serviceability-dev mailing list