RFR: 8370344: Arbitrary Java frames on stack during scoped access

[Chen Liang]

On Tue, 21 Oct 2025 16:00:49 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> See the JBS issue for a problem description.
> 
> This patch changes the shared scope closure handshake to be able to handle 'arbitrary' Java frames on the stack during a scoped memory access.
> 
> For the purposes of this change, we assume that 'arbitrary' is limited to the following: 
> 1. Frames added by calling the constructor of `InternalError` as a result of a faulting access to a truncated memory-mapped file (see `HandshakeState::handle_unsafe_access_error`). This is the only handshake operation (i.e. may be triggered during a scoped access) that calls back into Java.
> 2. Frames added by a JVMTI agent that calls back into Java code while handling a JVMTI event that happens during a scoped access.
> 3. Any other Java code that runs as part of the linking process.
> 
> For (1), we set a flag while we are create the `InternalError`. If a thread has that flag set, we know it is in the process of crashing already, so we don't have to inspect the stack at all. For (2), all bets are off, so we have to walk the entire stack. For (3), this patch switches the hard limit of 10 frames for the stack walk to instead bail out at the first frame outside of the `java.base` module. In most cases this speeds up the stack walk as well, if threads are running other code.
> 
> The test `TestSharedCloseJFR` is added for scenario (1), and the test `TestSharedCloseJvmti` is added for scenario (2). Existing tests already cover scenario (3).
> 
> Testing: tier 1-4

src/hotspot/share/prims/scopedMemoryAccess.cpp line 81:

> 79:     if (is_scoped) {
> 80:       assert(!would_have_bailed, "would have missed scoped method on release build");
> 81:       func(stream);

Why do we remove the short-circuiting here? For example, if we have is_accessing_session set to true already, why can't we short circuit?

test/jdk/java/foreign/sharedclosejfr/TestSharedCloseJFR.java line 30:

> 28:  * @requires vm.flavor != "zero"
> 29:  * @requires vm.debug
> 30:  * @requires vm.hasJFR

You can use & to require multiple conditions at once in one directive.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27919#discussion_r2474193541
PR Review Comment: https://git.openjdk.org/jdk/pull/27919#discussion_r2474079765