RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting [v4]

[Chen Liang]

On Mon, 8 Dec 2025 20:00:20 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   bracket styles
>
> src/java.base/share/classes/jdk/internal/vm/annotation/constant-folding.md line 12:
> 
>> 10: 
>> 11: Constant folding means a read of a variable of a constant value can be replaced
>> 12: by the read constant value, during the construction of an IR graph.  The
> 
> I think think constant folding encompasses much more than just field loads. E.g. folding `3 + 4` into `7` is also constant folding. More abstractly, I'd say that constant folding is essentially running a computation at compile time. The JIT compiler tries to do some of the computations in the code that it is compiling at compile time, so that they don't have to be done over and over when the compiled code is ran.
> 
> We can think of instance field loads as a computation that takes in an instance of an object, and returns the value of one of the fields. If the _input_ is a constant, it is that _computation_ that may be folded, and the _result_ of that computation is then also a constant. To do that fold, the JIT essentially has to determine if the computation will always return the same result when evaluated.
> 
> Another important condition for folding field loads is that the input to that computation is always the same: namely the instance from which the field is loaded. Even if a field is a trusted final, if the instance from which that field is loaded may vary, the JIT will not treat the value of that field as 'constant'. I don't think it's necessarily wrong to say that a field 'is constant', but that doesn't guarantee that the JIT is able to constant fold loads from that field.
> 
> I think the word 'constant' is a bit too vague on its own, and used to mean several different things. I detect some tension when reading the rest of this doc, where you say for instance 'may be constant', rather than the more decisive 'is constant'. For instance, a 'constant' is just a fixed value (such as '3'), but a 'constant field' is a field that can not be changed, and a load from a 'constant field' is not guaranteed to produce a (JIT) compile time 'constant'. I think you need to clearly define 'constant' earlier in the document, and potentially use different terms for these examples.

Sure, I have created https://bugs.openjdk.org/browse/JDK-8373286 to track that effort instead.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28540#discussion_r2600090805