8364588: Export the NPE backtracking functionality to general null-checking APIs

[liach]

Provide a general facility for our null check APIs like Objects::requireNonNull or future Checks::nullCheck (void), converting the existing infrastructure to start tracking from a given stack site (depth offset) and a given stack slot (offset value).

This is a necessary prerequisite for https://bugs.openjdk.org/browse/JDK-8233268, which proposes enhanced null messages to Objects::requireNonNull.

---

Progress

• Change must not contain extraneous whitespace
• Commit message must refer to an issue
• Change must be properly reviewed (3 reviews required, with at least 3 Reviewers)

Issue

• JDK-8364588: Export the NPE backtracking functionality to general null-checking APIs (Enhancement - P4)

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 26600

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

Using diff file

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

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back liach! 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]

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

• core-libs
• hotspot
• security

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]

Thanks for the preliminary review. After some thinking, to avoid wasting review cycles, I am pulling the common infrastructure for requireNonNull and Checks::nullCheck into a JDK-internal API, and the changes here are mostly confined to runtime.

[mlbridge]

Webrevs

• 03: Full - Incremental (4ba1f17c)
• 02: Full - Incremental (9af7ee85)
• 01: Full - Incremental (09233e9a)
• 00: Full (5735b802)

[dholmes-ora]

VM side seems reasonable. Java side looks a bit clunky but that is up to core-libs folk to evaluate.

General note: if comments start with a capital they should end with a period, and vice-versa. Extended comments should consist of full sentences.

Thanks.

[jdksjolen]

Still reading this. A few comments, mostly intended to make this easier to grok for future readers. The actual logic seems fine from a first read.

[openjdk]

⚠️ @liach This pull request contains merges that bring in commits not present in the target repository. Since this is not a "merge style" pull request, these changes will be squashed when this pull request in integrated. If this is your intention, then please ignore this message. If you want to preserve the commit structure, you must change the title of this pull request to Merge <project>:<branch> where <project> is the name of another project in the OpenJDK organization (for example Merge jdk:master).

[RogerRiggs]

/reviewers 3 reviewer
A hotspot and 2 core-libs reviewers should have a chance to comment.

[openjdk]

@RogerRiggs
The total number of required reviews for this PR (including the jcheck configuration and the last /reviewers command) is now set to 3 (with at least 3 Reviewers).

[bridgekeeper]

@liach This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply issue a /touch or /keepalive command to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

[liach]

/touch

[openjdk]

@liach The pull request is being re-evaluated and the inactivity timeout has been reset.

[jaikiran]

Hello Chen, I had a look at the changes, but I'm missing some broader context of this change.

The JBS issue and the PR description states that this PR is in preparation (to upcoming additional work?) to support better NullPointerException exception messages when some code uses Objects.requireNonNull(). It also talks about a java.lang.runtime.Checks::nullCheck method, but there's no such java.lang.runtime.Checks class in mainline and it appears to be a proposed class in Valhalla project (https://bugs.openjdk.org/browse/JDK-8357936). But there too it's non-existent for now. So I'll leave out the Checks class from this discussion.

If this change were to be integrated into mainline, would there be any change to NullPointerException exception messages in any code paths? If not, then would it better to do these changes along with the Objects.requireNonNull() change itself, as part of https://bugs.openjdk.org/browse/JDK-8233268? In JDK-8233268, there's also a comment from Goetz proposing how the new exception message should look like. If the current changes were to be done, would it allow for that proposal to be implemented?

I did have a brief look at the new jtreg test cases in this PR, but it wasn't immediately clear to me which APIs would start seeing this new proposed exception messages.

[liach]

Hi @jaikiran, this is currently neutral to mainline. I split the actual Objects.rNN changes because they have to go through CSR reviews. The actual change to hook it up was removed in 39c2d16.

The message is not the same as what Goetz Lindenmaier proposed, in part because the information about the source of the exception is already obvious in the stack traces (top level is always the null check API). I decided to only include which slot had null instead.

In the test suite, the new API to see the proposed new exception messages would be NullCheckAPITest::nullCheck. This demonstrates the flexibility of this new system I added.

[liach]

Can anyone come and review this little enhancement again? I think I have addressed the review comments.

[dholmes-ora]

So you define an ENUM to capture the negative cases but then you can use any int >= 0 and pretend it is a member of the enum. ?? Is that typical C++ enum usage?

[liach]

This was from @jdksjolen's suggestion. I emulated how valhalla's LayoutKind is declared.