RFR: 8254668: JVMTI process frames on thread without started processing

[Stefan Karlsson]

I hit the following assert in some tests runs that I've been doing:
# Internal Error (/home/stefank/git/alt/open/src/hotspot/share/runtime/stackWatermark.inline.hpp:67), pid=828170,
tid=828734 # assert(processing_started()) failed: Processing should already have started

The stack traces for this has been:
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0x1626d75] StackWatermarkSet::on_iteration(JavaThread*, frame const&)+0xd5
V [libjvm.so+0xad791a] frame::sender(RegisterMap*) const+0x7a
V [libjvm.so+0xacd3f8] frame::real_sender(RegisterMap*) const+0x18
V [libjvm.so+0x1804c4a] vframe::sender() const+0xea
V [libjvm.so+0x175f47b] JavaThread::last_java_vframe(RegisterMap*)+0x5b
V [libjvm.so+0x10e10fc] JvmtiEnvBase::vframeFor(JavaThread*, int)+0x4c
V [libjvm.so+0x10e6972] JvmtiEnvBase::check_top_frame(Thread*, JavaThread*, jvalue, TosState, Handle*)+0xe2
V [libjvm.so+0x10e759c] JvmtiEnvBase::force_early_return(JavaThread*, jvalue, TosState)+0x11c
V [libjvm.so+0x105b8f5] jvmti_ForceEarlyReturnObject+0x215
V  [libjvm.so+0x1626d75]  StackWatermarkSet::on_iteration(JavaThread*, frame const&)+0xd5
V  [libjvm.so+0xad791a]  frame::sender(RegisterMap*) const+0x7a
V  [libjvm.so+0xacd3f8]  frame::real_sender(RegisterMap*) const+0x18
V  [libjvm.so+0x1804c4a]  vframe::sender() const+0xea
V  [libjvm.so+0x1804d00]  vframe::java_sender() const+0x10
V  [libjvm.so+0x10e1115]  JvmtiEnvBase::vframeFor(JavaThread*, int)+0x65
V  [libjvm.so+0x10d475f]  JvmtiEnv::NotifyFramePop(JavaThread*, int)+0x9f
V  [libjvm.so+0x106b6aa]  jvmti_NotifyFramePop+0x23a
The code inspects the top frame of a suspended java thread. However, there's nothing in the code that starts the
watermark processing of the thread, so the code asserts when sender calls on_iteration.

We only have to call start_processing/on_iteration when oops are being read. The failing code does *not* inspect any
oops, so I turn of the on_iteration call by settings process_frame to false.

To notify the readers of the code that vframeFor doesn't process the oops, I've renamed the function to
vframeForNoProcess to give a visual cue.

I found this bug when running this command line:
makec ../build/fastdebug/ test TEST=test/hotspot/jtreg/vmTestbase/nsk/jvmti
JTREG="JAVA_OPTIONS=-XX:+UseZGC -Xmx2g -XX:ZCollectionInterval=1 -XX:ZFragmentationLimit=0.01"
JTREG_EXTRA_PROBLEM_LISTS=ProblemList-zgc.txt

Five tests consistently asserts with this command line. All tests pass with the proposed fix.

Recommendations of tests to run are welcome. I intend to get this run through tier1-3, but haven't yet.

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

Commit messages:
 - 8254668: JVMTI process frames on thread without started processing

Changes: https://git.openjdk.java.net/jdk/pull/627/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=627&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8254668
  Stats: 9 lines in 3 files changed: 1 ins; 0 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/627.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/627/head:pull/627

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