RFR: 8361842: Move input validation checks to Java for java.lang.StringCoding intrinsics [v8]

[Volkan Yazici]

On Thu, 17 Jul 2025 15:33:37 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> What is the thinking when an `@IntrinsicCandidate` method invokes another `@IntrinsicCandidate` method?
>> Which part is responsible for the checks?
>> 
>> For example, the Java code of `StringCoding.encodeISOArray0()` invokes `StringUTF16.getChar()`, another `@IntrinsicCandidate` method. The latter does not check its arguments (OK, there's an `assert`, but this is a weak check). The invocation from `encodeISOArray0()` is fine and safe, but `getChar()` is invoked by other parts of the code.
>> 
>> So what is the general strategy? Add checks to `getChar()` and rely on the runtime to eliminate redundant checks?
>
>> What is the thinking when an `@IntrinsicCandidate` method invokes another `@IntrinsicCandidate` method? Which part is responsible for the checks?
>> 
>> For example, the Java code of `StringCoding.encodeISOArray0()` invokes `StringUTF16.getChar()`, another `@IntrinsicCandidate` method. The latter does not check its arguments (OK, there's an `assert`, but this is a weak check). The invocation from `encodeISOArray0()` is fine and safe, but `getChar()` is invoked by other parts of the code.
>> 
>> So what is the general strategy? Add checks to `getChar()` and rely on the runtime to eliminate redundant checks?
> 
> To reformulate my confusing question for the above example, there are apparently around 75-80 invocations of `getChar()`. How to make sure that they are all safe? Some are easy to verify, but others are not.

Even though the `tier1,tier2,tier3,tier4,tier5,hs-comp-stress,hs-precheckin-comp` tests pass on several platforms, @rgiulietti pointed me other shortcomings regarding the recent lenient approach taken. Please allow me some time with this PR. I will keep this PR updated. :popcorn:

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

PR Comment: https://git.openjdk.org/jdk/pull/25998#issuecomment-3096882515