On Thu, 17 Jul 2025 15:33:37 GMT, Raffaello Giulietti <rgiulie...@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
