RFR: 8271140: Fix native frame handling in vframeStream::asJavaVFrame()

[Doug Simon]

On Thu, 22 Jul 2021 13:07:46 GMT, Andreas Woess <aw at openjdk.org> wrote:

> Follow-up to https://github.com/openjdk/jdk/pull/4625 ([JDK-8269592](https://bugs.openjdk.java.net/browse/JDK-8269592)) which added support for native frames to `vframeStreamCommon::asJavaVFrame()`. This change was not correct when `asJavaVFrame()` is called for a native frame that is the last frame on the stack (i.e. the first frame in the stream), in which case there's no `_prev_frame` yet. We don't actually need the extended frame information for native frames, so the fix is to just use the vframeStream's `_frame` and `_reg_map` for native frames.
> Extended the test from JDK-8269592 to cover this case.

test/hotspot/jtreg/compiler/jvmci/compilerToVM/IterateFramesNative.java line 47:

> 45:  *                   -XX:+DoEscapeAnalysis -XX:-UseCounterDecay
> 46:  *                   compiler.jvmci.compilerToVM.IterateFramesNative
> 47:  * @run main/othervm -Xbatch -Xcomp -Xbootclasspath/a:.

I think `-Xcomp` implies `-Xbatch`.
I think you should add `-XX:CompileOnly=jdk.vm.ci.hotspot.CompilerToVM::iterateFrames` since you only really care about that method being compiled for sake of the test.

test/hotspot/jtreg/compiler/jvmci/compilerToVM/IterateFramesNative.java line 50:

> 48:  *                   -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI
> 49:  *                   -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI
> 50:  *                   -XX:+DoEscapeAnalysis -XX:-UseCounterDecay

Are the `-XX:+DoEscapeAnalysis -XX:-UseCounterDecay` options really needed?

test/hotspot/jtreg/compiler/jvmci/compilerToVM/IterateFramesNative.java line 90:

> 88:                 ? CompilerWhiteBoxTest.THRESHOLD
> 89:                 : CompilerWhiteBoxTest.THRESHOLD * 2;
> 90: 

`COMPILE_THRESHOLD` looks unused.

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

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