On Tue, 21 Oct 2025 16:00:49 GMT, Jorn Vernee <[email protected]> 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 This pull request has now been integrated. Changeset: a51a0bf5 Author: Jorn Vernee <[email protected]> URL: https://git.openjdk.org/jdk/commit/a51a0bf57feaae0862fd7f3dbf305883d49781a0 Stats: 550 lines in 9 files changed: 534 ins; 5 del; 11 mod 8370344: Arbitrary Java frames on stack during scoped access Reviewed-by: pchilanomate, dholmes, liach ------------- PR: https://git.openjdk.org/jdk/pull/27919
