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

Ashutosh Mehra asmehra at openjdk.org
Tue Oct 14 13:16:20 UTC 2025


On Tue, 14 Oct 2025 09:12:09 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> 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.)
>
> Sorry, I guess that was my mistake. Changing it would be fine with me. Not a big deal, though.

I will update the label names to use the convention `L_name`.

>> 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.)
>
> True, but I also like the current implementation from a readability perspective.

Let's keep it for now. I will remove `VM_Version::supports_fast_class_init_checks()` from platform-specific code in a follow-up PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27676#discussion_r2429118079
PR Review Comment: https://git.openjdk.org/jdk/pull/27676#discussion_r2429123973


More information about the hotspot-dev mailing list