RFR: 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents [v9]

[Richard Reingruber]

On Sat, 10 Oct 2020 09:01:22 GMT, Richard Reingruber <rrich at 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 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.

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

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