8156534: Check if range checks can be moved into Java wrapper for intrinsics

[vy]

Warning

This is a draft PR to collect feedback on implementing JDK-8156534 only for java.lang.StringCodec::countPositives.

Moves String-related intrinsic checks from C++ to Java – see the ticket for details on motivation.

Implementation notes

The goal of this work is to, for java.lang.String* classes,

1. Move @IntrinsicCandidate-annotated public methods¹ (in Java code) to private ones, and wrap them with a public "front door" method
2. Since we moved the @IntrinsicCandidate annotation to a new method, intrinsic mappings – i.e., associated do_intrinsic() calls in vmIntrinsics.hpp – need to be updated too
3. Add range and null checks to the newly created public front door method
4. Place all range and null checks in the intrinsic code (add if missing!) behind a VerifyIntrinsicChecks flag

Following preliminary work needs to be carried out as well:

1. Add a new VerifyIntrinsicChecks VM flag
2. Update generate_string_range_check to produce a HaltNode

¹ @IntrinsicCandidate-annotated constructors are not subject to this change, since they are a special case.

Verification

I've tested the implementation as follows:

1. Created the following test program:

public class StrIntri {
    public static void main(String[] args) {
        Exception lastException = null;
        for (int i = 0; i < 1_000_000; i++) {
            try {
                jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[1,2,3], 2, 5);
            } catch (Exception exception) {
                lastException = exception;
            }
        }
        if (lastException != null) {
            lastException.printStackTrace();
        } else {
            System.out.println("completed");
        }
    }
}

2. Compiled the JDK and run the test:

$ CONF=linux-x64-slowdebug make jdk
$ ~/jdk/build/linux-x64-slowdebug/jdk/bin/java -XX:+VerifyIntrinsicChecks --add-exports java.base/jdk.internal.access=ALL-UNNAMED StrIntri.java
java.lang.IndexOutOfBoundsException: Range [2, 2 + 5) out of bounds for length 3

Received IOOBE as expected.

3. Removed all checks in StringCodec.java, and re-compiled the JDK
4. Set the countPositives(...) arguments in the program to (null, 1, 1), run it, and observed the VM crash with unexpected null in intrinsic.
5. Set the countPositives(...) arguments in the program to (new byte[]{1,2,3}, 2, 5), run it, and observed the VM crash with unexpected guard failure in intrinsic.

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change must not contain extraneous whitespace
• Commit message must refer to an issue

Issue

• JDK-8156534: Check if range checks can be moved into Java wrapper for intrinsics (Enhancement - P2)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/25998/head:pull/25998
$ git checkout pull/25998

Update a local copy of the PR:
$ git checkout pull/25998
$ git pull https://git.openjdk.org/jdk.git pull/25998/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 25998

View PR using the GUI difftool:
$ git pr show -t 25998

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/25998.diff

[bridgekeeper]

👋 Welcome back vyazici! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

[openjdk]

@vy The following labels will be automatically applied to this pull request:

• core-libs
• graal
• hotspot

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing lists. If you would like to change these labels, use the /label pull request command.

[liach]

I recall core libraries intentionally avoided this because of performance problems. Is it possible for us to say trust the len argument to be non-negative? That allows us to simplify this to Objects.checkIndex(off, ba.length - len). See this usage in perf-sensitive FFM API:

jdk/src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java

Line 401 in 1498824

void checkBounds(long offset, long length) {

[TobiHartmann]

But the original code already checks for len >= 0, right? See LibraryCallKit::inline_countPositives -> generate_string_range_check -> // Offset and count must not be negative

This PR is about moving the range checks from the intrinsics into the Java wrappers. Removing range checks is out of the scope and should be carefully evaluated on a case-by-case basis separately.

[liach]

My point is this is a performance-sensitive API. We are using a known-slow check method checkFromIndexSize which may introduce a performance regression.

[ExE-Boss]

Maybe use jdk.internal.util.Preconditions directly instead?

Suggested change

	Objects.checkFromIndexSize(off, len, ba.length);
	Preconditions.checkFromIndexSize(off, len, ba.length, null);