See the JBS issue for the full explanation of the issue. Now that https://github.com/openjdk/jdk/pull/25315 was integrated, we are able to reliably scan for session oops in a frame, and only deoptimize those frames where the oop is live.
I ran the `ConcurrentClose` benchmark before and after this patch, and these were the results: Before: Benchmark Mode Cnt Score Error Units ConcurrentClose.sharedClose avgt 10 10.139 ± 0.416 us/op ConcurrentClose.sharedClose:closing avgt 10 29.288 ± 1.257 us/op ConcurrentClose.sharedClose:memorySegmentAccess avgt 10 0.651 ± 0.030 us/op ConcurrentClose.sharedClose:otherAccess avgt 10 0.478 ± 0.026 us/op After: Benchmark Mode Cnt Score Error Units ConcurrentClose.sharedClose avgt 10 9.860 ± 0.387 us/op ConcurrentClose.sharedClose:closing avgt 10 28.641 ± 1.175 us/op ConcurrentClose.sharedClose:memorySegmentAccess avgt 10 0.470 ± 0.013 us/op ConcurrentClose.sharedClose:otherAccess avgt 10 0.468 ± 0.015 us/op We can see that now the unrelated memory access in `memorySegmentAccess` is no longer being affected by a scope being closed in another thread. Testing: `jdk_foreign` suite, and I repeat ran `java/foreign/TestHandshake.java` 50 times as well, which is our stress test for shared scopes. --------- - [x] I confirm that I make this contribution in accordance with the [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). ------------- Commit messages: - Merge branch 'master' into ScanOops - Scan for session oop before deoptimizing Changes: https://git.openjdk.org/jdk/pull/30926/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=30926&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8383244 Stats: 39 lines in 1 file changed: 27 ins; 8 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/30926.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/30926/head:pull/30926 PR: https://git.openjdk.org/jdk/pull/30926
