On Fri, 24 Apr 2026 15:36:37 GMT, Jorn Vernee <[email protected]> wrote:
> 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). This pull request has now been integrated. Changeset: d40df6cf Author: Jorn Vernee <[email protected]> URL: https://git.openjdk.org/jdk/commit/d40df6cfd85ef42b66a0af22c123ed7680d9d004 Stats: 380 lines in 4 files changed: 333 ins; 31 del; 16 mod 8383244: Shared scope closure should only deoptimize if the scope oop is live Reviewed-by: vlivanov, dlong ------------- PR: https://git.openjdk.org/jdk/pull/30926
