On Mon, 7 Sep 2026 12:30:40 GMT, Jorn Vernee <[email protected]> wrote:
>> Question... does the `has_scoped_access` machinery still carry weight? We >> did that originally to prevent deoptimization in cases that had nothing to >> do with memory access. Now it becomes more of a way to avoid the JNI >> resolution. This might still be important -- but I wonder if we have numbers >> to back up the need for two separate mechanisms here? > >> does the has_scoped_access machinery still carry weight? > > I'd say yes. The scope oop could be live inside a frame that is not doing a > memory access as well. We still want to avoid deoptimizing in that case. The > `is_session_live` check alone does not detect whether we're doing a memory > access or not, and we're already in the scenario where we're not inside > `@Scoped` code. > > In other words, these two mechanisms do different things. `has_scoped_access` > detects any scoped accesses in the frame, while `is_session_live` detects > _any_ use of the session. FWIW, I've been trying to get some numbers for this, but JMH doesn't really seem equipped to handle this situation. We need to share a shared arena with two threads, where one thread does something with the scope oop so it's kept alive at a safepoint, while the other thread closes the arena. I've got the right code setup for the oop to be live at a safepoint without doing a memory access (we can just get it from `Arena::scope`), but the issue is that closing the arena requires creating a new one every invocation, and JMH will do per-invocation setup independently for every benchmark method, even if the benchmark state is shared within the same thread group (the different threads will just race to initialize the state before every invocation). So, one thread will happily create many different arenas while another is still busy closing just the one. I could try to add some kind of synchronization where the accessing thread will wait for the closing thread to try and ensure they use the same arena, but that will make the numbers we get out of the measurement pretty much useless, since we're just measuring the wait time in that case. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/30926#discussion_r3952165294
