This cause asserts like this:

# 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

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

The proposal is to dodge this problem by turning of "frame processing" for these calls. The processing is only needed when oops are read, and the current code doesn't read oops.