RFR: 8369296: Add fast class init checks in interpreter for resolving ConstantPool entries for static field [v2]

[Vladimir Kozlov]

On Tue, 7 Oct 2025 18:22:21 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>>> > Can we loop to L_clinit_barrier_slow several times until class is initialized?
>>> 
>>> No, `clinit_barrier` either "blocks" (not yet initialized or being initialized, but not in init thread) or returns right away (fully initialized or being initialized and in init thread). No need for repeated attempts.
>> 
>> First, what do you mean "blocks"? It wait something with lock?
>> 
>> Second, my question was that slow path in `clinit_barrier` will jump to `L_clinit_barrier_slow` which is before `clinit_barrier` there are no branch there so after `call_VM` we again will call `clinit_barrier`? what I am missing?
>
>> First, what do you mean "blocks"? It wait something with lock?
> 
>> Second, my question was that slow path in clinit_barrier will jump to L_clinit_barrier_slow which is before clinit_barrier there are no branch there so after call_VM we again will call clinit_barrier? what I am missing?
> 
> `clinit_barrier` itself doesn't block. Its a quick check for class fully initialized or the current thread is the init thread. If not, then it jumps to the slow path. In this case slow path is the call to `InterpreterRuntime::resolve_from_cache` which may initialize the klass or get blocked if the klass is being initialized by another thread.
> After returning it again executes `clinit_barrier`. But this time the class should have initialized, so it just falls through.
> 
> Also, I think `clinit_barrier` is not a very accurate name because it doesn't cause initialization of the klass. I think `fast_clinit_check` better conveys what it is doing, but that renaming can be done later if required.

Thank you @ashu-mehra  for explanation. So we can call `clinit_barrier` second time but not more. Good.

> fast_clinit_check better conveys what it is doing,

Agree.

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

PR Comment: https://git.openjdk.org/jdk/pull/27676#issuecomment-3378084056