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