8329764: G1: Handle null references during verification first

[tschatzl]

Hi all,

please review this change that suggests to move the null reference check in object iteration during heap verification first.

The reason is as stated, since null references are fairly common (not only in that test mentioned in https://bugs.openjdk.org/browse/JDK-8329314), it may make sense to put it first. Also, null references never fail anyway (and verification failure is supposed to be uncommon).

Improves total runtime of that test case from 3s (~3.9s cpu time) to 2.2s (~3.1s cpu time).

If you think it makes the code too ugly, I will retract it.

Testing: gha, local testing.

---

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-8329764: G1: Handle null references during verification first (Enhancement - P4)

Reviewers

• Stefan Karlsson (@stefank - Reviewer)
• Ivan Walulya (@walulyai - Reviewer)

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 18650

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

Using diff file

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

Webrev

Link to Webrev Comment

[bridgekeeper]

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

[openjdk]

@tschatzl This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8329764: G1: Handle null references during verification first

Reviewed-by: stefank, iwalulya

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 66 new commits pushed to the master branch:

• 60d88b7: 8330176: Typo in Linker javadoc
• 3f1d9c4: 8329257: AIX: Switch HOTSPOT_TOOLCHAIN_TYPE from xlc to gcc
• 5404b4e: 8330105: SharedRuntime::resolve* should respect interpreter-only mode
• d22d560: 8329864: TestLibGraal.java still crashes with assert(_stack_base != nullptr)
• bc1a1a5: 8330064: JFR: Incorrect function declarations for register/unregister_stack_filter
• b486709: 8328480: C2: SubTypeCheckNode in checkcast should use the klass constant of a unique concrete sub class
• 1abb826: 8330131: Problemlist serviceability/jvmti/vthread/GetThreadStateMountedTest/GetThreadStateMountedTest.java
• c1c99a6: 8329674: JvmtiEnvThreadState::reset_current_location function should use JvmtiHandshake
• b9ef9f6: 8330185: Potential uncaught unsafe memory copy exception
• 28b2019: 8240343: JDI stopListening/stoplis001 "FAILED: listening is successfully stopped without starting listening"
• ... and 56 more: https://git.openjdk.org/jdk/compare/2e925f263d5a9a69f21e0c12bd71242fdff084cd...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

[openjdk]

@tschatzl The following label will be automatically applied to this pull request:

• hotspot-gc

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

[mlbridge]

Webrevs

• 02: Full (e6e9fefa)
• 01: Full - Incremental (a6eecee0)
• 00: Full (a6eecee0)

[tschatzl]

Fwiw, removing the assert(_containing_obj != nullptr but keeping other code as is gives the following results: runtime 2.65s (cpu time 3.2s), so it may still be worth changing the code as suggested.

[openjdk-notifier]

The parent pull request that this pull request depends on has now been integrated and the target branch of this pull request has been updated. This means that changes from the dependent pull request can start to show up as belonging to this pull request, which may be confusing for reviewers. To remedy this situation, simply merge the latest changes from the new target branch into this pull request by running commands similar to these in the local repository for your personal fork:

git checkout submit/8329764-verification-null-refs-first
git fetch https://git.openjdk.org/jdk.git master
git merge FETCH_HEAD
# if there are conflicts, follow the instructions given by git merge
git commit -m "Merge master"
git push

[stefank]

I integrated the simplest version of #18595 now. I still think it would be nice to clean away the assert(_containing_obj...) with my proposed changes. Should I do that? Or do you have some other plan for it?

[tschatzl]

I integrated the simplest version of #18595 now. I still think it would be nice to clean away the assert(_containing_obj...) with my proposed changes. Should I do that? Or do you have some other plan for it?

I am good with moving the assert too (not sure if it is worth an extra change or adding it here); however this change, i.e. moving the condition, would improve performance beyond moving the assert as shown above.

The other changes from you about extracting the failure counter could be done as well - when refactoring this verification code the last time the extra 30 LOC or so did not seem worth to me, but the code is already fairly large.

There are no further plans from me to improve verification performance further, apart from maybe filing a CR to parallelize verification of large object arrays.

Does that answer your questions?

[stefank]

I integrated the simplest version of #18595 now. I still think it would be nice to clean away the assert(_containing_obj...) with my proposed changes. Should I do that? Or do you have some other plan for it?

I am good with moving the assert too (not sure if it is worth an extra change or adding it here); however this change, i.e. moving the condition, would improve performance beyond moving the assert as shown above.

The other changes from you about extracting the failure counter could be done as well - when refactoring this verification code the last time the extra 30 LOC or so did not seem worth to me, but the code is already fairly large.

There are no further plans from me to improve verification performance further, apart from maybe filing a CR to parallelize verification of large object arrays.

Does that answer your questions?

I had hoped for a more clear yes or no. :)

[tschatzl]

I integrated the simplest version of #18595 now. I still think it would be nice to clean away the assert(_containing_obj...) with my proposed changes. Should I do that? Or do you have some other plan for it?

I am good with moving the assert too (not sure if it is worth an extra change or adding it here); however this change, i.e. moving the condition, would improve performance beyond moving the assert as shown above.
The other changes from you about extracting the failure counter could be done as well - when refactoring this verification code the last time the extra 30 LOC or so did not seem worth to me, but the code is already fairly large.
There are no further plans from me to improve verification performance further, apart from maybe filing a CR to parallelize verification of large object arrays.
Does that answer your questions?

I had hoped for a more clear yes or no. :)

If unsure: Please move the assert and add the failure counter changes :) Would be nice to have.

Thomas

[stefank]

I've opened #18677 for the null-check and failure counting.

[tschatzl]

Still saving ~200ms (release build) verifying that large array.

[tschatzl]

500ms on a fastdebug build.

[albertnetymk]

I was think of something similar, also makes the iteration actually stop at G1MaxVerifyFailures instead of at some related but arbitrary larger number.

From #18595

Stopping field-iteration at the specified limit sounds much nicer; can that be done instead of (or in addition to) this reordering?

[tschatzl]

I was think of something similar, also makes the iteration actually stop at G1MaxVerifyFailures instead of at some related but arbitrary larger number.

From #18595

Stopping field-iteration at the specified limit sounds much nicer; can that be done instead of (or in addition to) this reordering?

I am not completely sure what the exact goal of stopping field-iteration at specified limit is, however I think both options are orthonal: this change speeds up the common case (no error, null references), while the other would presumably make the VM exit faster in the failure case and/or guarantees to write only a particular amount of failure messages?

Just brainstorming:

• making the VM exit faster after an error would require some way to abort iteration (or at least split iteration into parts for large objarrays?),
• making the VM observe G1MaxVerifyFailure better (at the moment it is like #verification threads * G1MaxVerifyFailure) would need some global synchronization, which would make it much slower again I guess?

In any case these two efforts seem to be completely independent.

As mentioned initially, I am okay to just close this PR, but it seems low hanging fruit obtained with little effort.

[stefank]

Looks good to me.

[albertnetymk]

this change speeds up the common case (no error, null references),

That's true, but the new logic is kind of surprising -- the threshold is checked after we de-ref the field; I would have expected the threshold controls the field-iteration/de-ref.

making the VM exit faster after an error would require some way to abort iteration

I've noticed that the current iteration API lacks support for early returns...

In the optimal scenario:

for (field in obj) {
  oop = *field;

  if (oop == null)
    continue;

  if (!is_correct(oop)) {
    ++failure;
    if (failure >= threshold) {
      break;
    }
  }
}

Since threshold is only accessed during failure cases, the impact on performance should be minimal.

(This implementation relies on a new iteration API, and there may be overlooked details necessary for its proper functionality. Feel free to merge the current PR.)

[tschatzl]

this change speeds up the common case (no error, null references),

That's true, but the new logic is kind of surprising -- the threshold is checked after we de-ref the field; I would have expected the threshold controls the field-iteration/de-ref.

That is why I consider this change "ugly" as well.

Looking at perf counters, my hunch is that the two loads for the current failure counter and the bound (and comparison) are just much more expensive (in terms of cpu resources even if both branches are easily predicted) than the single pointer deref and check against null.

[tschatzl]

thanks @stefank @walulyai for your reviews
/integrate

[openjdk]

Going to push as commit a3fecdb.
Since your change was applied there have been 66 commits pushed to the master branch:

• 60d88b7: 8330176: Typo in Linker javadoc
• 3f1d9c4: 8329257: AIX: Switch HOTSPOT_TOOLCHAIN_TYPE from xlc to gcc
• 5404b4e: 8330105: SharedRuntime::resolve* should respect interpreter-only mode
• d22d560: 8329864: TestLibGraal.java still crashes with assert(_stack_base != nullptr)
• bc1a1a5: 8330064: JFR: Incorrect function declarations for register/unregister_stack_filter
• b486709: 8328480: C2: SubTypeCheckNode in checkcast should use the klass constant of a unique concrete sub class
• 1abb826: 8330131: Problemlist serviceability/jvmti/vthread/GetThreadStateMountedTest/GetThreadStateMountedTest.java
• c1c99a6: 8329674: JvmtiEnvThreadState::reset_current_location function should use JvmtiHandshake
• b9ef9f6: 8330185: Potential uncaught unsafe memory copy exception
• 28b2019: 8240343: JDI stopListening/stoplis001 "FAILED: listening is successfully stopped without starting listening"
• ... and 56 more: https://git.openjdk.org/jdk/compare/2e925f263d5a9a69f21e0c12bd71242fdff084cd...master

Your commit was automatically rebased without conflicts.

[openjdk]

@tschatzl Pushed as commit a3fecdb.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.