On Mon, 1 Dec 2025 18:27:34 GMT, Chen Liang <[email protected]> wrote:
>> Currently, the hotspot compiler (as in ciField) trusts final fields in >> hidden classes, record classes, and selected jdk packages. Some classes in >> the JDK wish to be trusted, but they cannot apply package-wide opt-in due to >> other legacy classes in the package, such as java.util. >> >> They currently can use `@Stable` as a workaround, but this is fragile >> because a stable final field may hold a trusted null, zero, or false value, >> which is currently treated as non-constant by ciField. >> >> We should add an annotation to opt-in for a whole class, mainly for legacy >> packages. This would benefit greatly some of our classes already using a lot >> of Stable, such as java.util.Optional, whose empty instance is now >> constant-foldable, as demonstrated in a new IR test. >> >> Paging @minborg who requested Optional folding for review. >> >> I think we can remove redundant Stable in a few other java.util classes >> after this patch is integrated. I plan to do that in subsequent patches. > > Chen Liang has updated the pull request incrementally with one additional > commit since the last revision: > > bracket styles I had a look at the document you wrote, but I think it still needs some work. I suggest maybe splitting that out into a separate PR. 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. ------------- PR Review: https://git.openjdk.org/jdk/pull/28540#pullrequestreview-3553830433 PR Review Comment: https://git.openjdk.org/jdk/pull/28540#discussion_r2599952662
