On Wed, 28 Jan 2026 16:23:21 GMT, Damon Fenacci <[email protected]> wrote:

>> ## Issue
>> 
>> This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) 
>> which was backed out by 
>> [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related 
>> regressions. The original change moved input validation checks for 
>> java.lang.StringCoding from the intrinsic to Java code (leaving the 
>> intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the 
>> [original PR](https://github.com/openjdk/jdk/pull/25998) for details.
>> 
>> This additional issue happens because, in some cases, for instance when the 
>> Java checking code is not inlined and we give an out-of-range constant as 
>> input, we fold the data path but not the control path and we crash in the 
>> backend.
>> 
>> ## Causes
>> 
>> The cause of this is that the out-of-range constant (e.g. -1) floats into 
>> the intrinsic and there (assuming the input is valid) we add a constraint to 
>> its type to positive integers (e.g. to compute the array address) which 
>> makes it top.
>> 
>> ## Fix
>> 
>> A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to 
>> what we do in `must_be_not_null` for values that we know cannot be null:
>> https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484
>> This will temporarily add the range check to ensure that C2 figures that 
>> out-of-range values cannot reach the intrinsic. Then, during macro 
>> expansion, we replace the opaque node with the corresponding constant 
>> (true/false) in product builds such that the actually unneeded guards are 
>> folded and do not end up in the emitted code.
>> 
>> # Testing
>> 
>> * Tier 1-3+
>> * 2 JTReg tests added
>>   * `TestRangeCheck.java` as regression test for the reported issue
>>   * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added 
>> when parsing and removed at macro expansion
>
> Damon Fenacci has updated the pull request incrementally with two additional 
> commits since the last revision:
> 
>  - JDK-8374582: fix comment layout
>  - JDK-8374582: fix constructor argument name

Copyright years don't point to 2026 for the following touched files:


src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp
src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.cpp
src/hotspot/cpu/x86/macroAssembler_x86.cpp
src/hotspot/share/classfile/vmIntrinsics.hpp
src/hotspot/share/opto/classes.hpp
src/hotspot/share/opto/escape.cpp
src/hotspot/share/opto/library_call.cpp
src/hotspot/share/opto/library_call.hpp
src/hotspot/share/opto/loopTransform.cpp
src/hotspot/share/opto/loopopts.cpp
src/hotspot/share/opto/macro.cpp
src/hotspot/share/opto/node.hpp
src/hotspot/share/opto/opaquenode.cpp
src/hotspot/share/opto/opaquenode.hpp
src/hotspot/share/opto/split_if.cpp
src/java.base/share/classes/java/lang/String.java
src/java.base/share/classes/java/lang/StringCoding.java
src/java.base/share/classes/java/lang/System.java
src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java
src/java.base/share/classes/sun/nio/cs/CESU_8.java
src/java.base/share/classes/sun/nio/cs/DoubleByte.java
src/java.base/share/classes/sun/nio/cs/ISO_8859_1.java
src/java.base/share/classes/sun/nio/cs/SingleByte.java
src/java.base/share/classes/sun/nio/cs/US_ASCII.java
src/java.base/share/classes/sun/nio/cs/UTF_8.java
src/jdk.charsets/share/classes/sun/nio/cs/ext/EUC_JP.java.template
test/hotspot/jtreg/compiler/escapeAnalysis/TestCanReduceCheckUsersDifferentIfs.java
test/hotspot/jtreg/compiler/lib/ir_framework/IRNode.java
test/hotspot/jtreg/compiler/unsafe/OpaqueAccesses.java

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

PR Review: https://git.openjdk.org/jdk/pull/29164#pullrequestreview-3718529560

Reply via email to