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

[Vladimir Ivanov]

On Fri, 10 Oct 2025 17:48:56 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>> This patch adds fast clinit barrier in the interpreter when resolving cp entry for a static field.
>> 
>> Testing: tested x86-64 by running `hotspot_runtime` group
>> Specifically, `runtime/clinit/ClassInitBarrier.java` fails if the block for adding `clinit_barrier` is commented out in `TemplateTable::resolve_cache_and_index_for_field`
>
> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove blank lines
>   
>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

src/hotspot/cpu/aarch64/templateTable_aarch64.cpp line 2272:

> 2270:   assert(byte_no == f1_byte || byte_no == f2_byte, "byte_no out of range");
> 2271: 
> 2272:   Label Lclinit_barrier_slow, Ldone;

Minor comment: why don't you use `L_name` instead? `Lname` is a new idiom for naming labels on most of the platforms. (The convention is either `L_name` or simply `name` almost everywhere.)

src/hotspot/cpu/aarch64/templateTable_aarch64.cpp line 2289:

> 2287: 
> 2288:   // Class initialization barrier for static methods
> 2289:   if (VM_Version::supports_fast_class_init_checks() && bytecode() == Bytecodes::_invokestatic) {

FTR `VM_Version::supports_fast_class_init_checks()` is redundant in platform-specific code. 

The method is intended to be used in shared code to support dispatching between 2 execution modes, but for each platform is it known well ahead whether fast class init checks are supported or not.

(It does make sense to keep it as an assert through.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27676#discussion_r2427368272
PR Review Comment: https://git.openjdk.org/jdk/pull/27676#discussion_r2427371470