On Sun, 11 Oct 2020 07:20:07 GMT, Richard Reingruber <rr...@openjdk.org> wrote:
>>> >>> >>> I tried to run testing with latest changes and latest JDK and build failed: >>> src/hotspot/share/runtime/escapeBarrier.cpp:310:35: error: no matching >>> function for call to >>> 'StackFrameStream::StackFrameStream(JavaThread*&)' 310 | StackFrameStream >>> fst(deoptee); >> >> I noticed this too. I wanted to test with ZGC before pushing the small >> fix. Unfortunately I get >> >> # Internal Error >> (/priv/d038402/git/reinrich/jdk_ea_new/src/hotspot/share/runtime/stackWatermark.inline.hpp:67), >> pid=90890, tid=90912 # assert(processing_started()) failed: Processing >> should already have started >> >> [...] >> >> Current thread (0x00007f749c25b1c0): JavaThread "JDWP Transport Listener: >> dt_socket" daemon [_thread_in_vm, id=90912, >> stack(0x00007f7474c9f000,0x00007f7474da0000)] >> _threads_hazard_ptr=0x00007f749c2b00c0, _nested_threads_hazard_ptr_cnt=0 >> Stack: [0x00007f7474c9f000,0x00007f7474da0000], sp=0x00007f7474d9c240, >> free space=1012k >> Native frames: (J=compiled Java code, A=aot compiled Java code, >> j=interpreted, Vv=VM code, C=native code) >> V [libjvm.so+0x15b3255] StackWatermarkSet::on_iteration(JavaThread*, frame >> const&)+0xa5 >> V [libjvm.so+0xa1024f] frame::sender(RegisterMap*) const+0x13f >> V [libjvm.so+0xa048f8] frame::real_sender(RegisterMap*) const+0x18 >> V [libjvm.so+0x176261b] vframe::sender() const+0xeb >> V [libjvm.so+0x16cd56b] JavaThread::last_java_vframe(RegisterMap*)+0x5b >> V [libjvm.so+0xfa7a56] JvmtiEnvBase::vframeFor(JavaThread*, int)+0x46 >> V [libjvm.so+0xfab8e5] JvmtiEnvBase::check_top_frame(JavaThread*, >> JavaThread*, jvalue, TosState, Handle*)+0x1f5 >> V [libjvm.so+0xfac13e] JvmtiEnvBase::force_early_return(JavaThread*, >> jvalue, TosState)+0x15e >> V [libjvm.so+0xf36fa8] jvmti_ForceEarlyReturnLong+0x258 >> C [libjdwp.so+0xa8b3] forceEarlyReturn+0x293 >> C [libjdwp.so+0x12945] debugLoop_run+0x1f5 >> C [libjdwp.so+0x25bb3] attachThread+0x33 >> V [libjvm.so+0xfcf524] JvmtiAgentThread::call_start_function()+0x1d4 >> V [libjvm.so+0x16cc8f7] JavaThread::thread_main_inner()+0x247 >> V [libjvm.so+0x16d1ce8] Thread::call_run()+0xf8 >> V [libjvm.so+0x12dd75e] thread_native_entry(Thread*)+0x10e >> >> In the test case >> `EAForceEarlyReturnOfInlinedMethodWithScalarReplacedObjectsReallocFailure` >> of the >> new test `jdk/com/sun/jdi/EATests.java` >> >> So far I do not have an indication that the failure is caused by this change >> but >> when I run the test with -XX:-DoEscapeAnalysis then the test succeeds. >> >> I need to look more into it. Wish I was a ZGC expert :) >> >> Anyway I pushed the build fix. Tests succeed with default GC. > > The crash described above happens after JDK-8253180 > (https://github.com/openjdk/jdk/commit/b9873e18330b7e43ca47bc1c0655e7ab20828f7a) > when executing `EATests.java` with > ZGC: make run-test TEST=test/jdk/com/sun/jdi/EATests.java > JTREG=VM_OPTIONS=-XX:+UseZGC > > My understanding of JDK-8253180 (and ZGC) is rather vague. To me it looks as > if stackwalks outside of a > safepoint/handshake on suspended threads are currently not supported. It > would be my understanding that > `StackWatermarkSet::start_processing()` needs to be called before walking the > stack of a thread. Currently this is only > done in preparation of a safepoint or handshake. > `JvmtiEnvBase::check_top_frame()` walks the stack of a suspended > thread without safepoint/handshake. This triggers the crash in my opinion. > When `StackWatermarkSet::start_processing()` > is called before the test succeeds. I will ask Erik Österlund about this. The issues with ZGC concurrent thread stack processing will be resolved with #627 ------------- PR: https://git.openjdk.java.net/jdk/pull/119
