> `JVM_MoreStackWalk` has a bug that always assumes that the Java frame > stream is currently at the frame decoded in the last patch and so always > advances to the next frame before filling in the new batch of stack frame. > However `JVM_MoreStackWalk` may return 0. The library will set > the continuation to its parent. It then call `JVM_MoreStackWalk` to continue > the stack walking but the last decoded frame has already been advanced. > The Java frame stream is already at the top frame of the parent continuation. > . > The current implementation skips "Continuation::yield0" mistakenly. This > only happens with `-XX:+ShowHiddenFrames` or > `StackWalker.Option.SHOW_HIDDEN_FRAMES`. > > The fix is to pass the number of frames decoded in the last batch to > `JVM_MoreStackWalk` > so that the VM will determine if the current frame should be skipped or not. > > `test/jdk/jdk/internal/vm/Continuation/Scoped.java` test now correctly checks > the expected result where "yield0" exists between "enter" and "run" frames.
Mandy Chung has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8316456 - call setBatch to update origin and fence for an empty batch - 8316456: StackWalker may skip Continuation::yield0 frame mistakenly ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15804/files - new: https://git.openjdk.org/jdk/pull/15804/files/f3ec0dac..ddaeaf99 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15804&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15804&range=00-01 Stats: 19285 lines in 295 files changed: 11045 ins; 7282 del; 958 mod Patch: https://git.openjdk.org/jdk/pull/15804.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15804/head:pull/15804 PR: https://git.openjdk.org/jdk/pull/15804
