8329982: compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/SimpleDebugInfoTest.java failed assert(oopDesc::is_oop_or_null(val)) failed: bad oop found

[dougxc]

This PR adds the missing nmethod entry barriers to JVMCI hand assembled tests.
It also closes the escape hatch in jvmciCodeInstaller.cpp that allowed JVMCI code to be installed without nmethod entry barriers.

---

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-8329982: compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/SimpleDebugInfoTest.java failed assert(oopDesc::is_oop_or_null(val)) failed: bad oop found (Bug - P3)

Reviewers

• Tom Rodriguez (@tkrodriguez - Reviewer)

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 19035

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

Using diff file

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

Webrev

Link to Webrev Comment

[bridgekeeper]

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

@dougxc 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:

8329982: compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/SimpleDebugInfoTest.java failed assert(oopDesc::is_oop_or_null(val)) failed: bad oop found

Reviewed-by: never

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 59 new commits pushed to the master branch:

• b33096f: 8295153: java/util/Base64/TestEncodingDecodingLength.java ran out of memory
• cf2c80e: 8331582: Incorrect default Console provider comment
• 77b7122: 8312104: Update java man pages to include new security category in -XshowSettings
• 87bb66c: 8331569: G1: Rename G1HRPrinter to G1HeapRegionPrinter
• 37c2469: 8331633: Use MIN2 in bound_minus_alignment
• 1d083eb: 8331562: G1: Remove API to force allocation of new regions
• 9697bc3: 8331428: ubsan: JVM flag checking complains about MaxTenuringThresholdConstraintFunc, InitialTenuringThresholdConstraintFunc and AllocatePrefetchStepSizeConstraintFunc
• ce73fec: 8331048: G1: Prune rebuild candidates based on G1HeapWastePercent early
• 58ef9e4: 8331402: G1: Remove is_active() calls in G1HRPrinter logging
• 3c77dad: 8331507: JFR: Improve example usage in -XX:StartFlightRecording:help
• ... and 49 more: https://git.openjdk.org/jdk/compare/4f529f8c232b4082aa4aa39766bcf42b09885ee4...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]

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

• graal
• hotspot-compiler

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.

[mlbridge]

Webrevs

• 02: Full - Incremental (1b30b67e)
• 01: Full - Incremental (be4bf630)
• 00: Full (62b3ad29)

[tkrodriguez]

This line is no longer needed.

[tkrodriguez]

In the long term I'm not sure it's worth trying to maintain these assembler tests. The barrier verification code is very weak and on aarch64 it's slightly complicated so we're barely checking that it really matches. I guess this is good enough until we get further problems.

I think you can simplify some other logic that deals with the optionality of the barrier. Start with removing JVMCINMethodData::has_entry_barrier and maybe update some of the comments to reflect that it's always emitted. And places that check _nmethod_entry_patch_offset for -1 can be removed or weakened.

[dougxc]

In the long term I'm not sure it's worth trying to maintain these assembler tests. The barrier verification code is very weak and on aarch64 it's slightly complicated so we're barely checking that it really matches. I guess this is good enough until we get further problems.

I agree. I had to push more changes now to remove tests that expect to be able to install 0 length code (which obviously fail the nmethod barrier verification). These tests provided stop gap coverage in the early days of JVMCI but now test functionality where breakage will clearly show up in higher layers (such as Graal). What's more, expanding the assembler support in JVMCI is redundant with the fully fledged assembler in Graal.

I think you can simplify some other logic that deals with the optionality of the barrier. Start with removing JVMCINMethodData::has_entry_barrier and maybe update some of the comments to reflect that it's always emitted. And places that check _nmethod_entry_patch_offset for -1 can be removed or weakened.

I've done that now. Please let me know if you can spot any other vestiges of the optional support.

[dean-long]

Wouldn't it be useful for the JVMCI implementation to provide the nmethod entry barrier code? I could be wrong, but I think all the JIT compiler needs to know is how big it is, so it can reserve the space (NOPs would do), then when the code is installed as an nmethod, memcpy it over (if it's static), or use the MacroAssembler if it's not.

[dougxc]

Wouldn't it be useful for the JVMCI implementation to provide the nmethod entry barrier code? I could be wrong, but I think all the JIT compiler needs to know is how big it is, so it can reserve the space (NOPs would do), then when the code is installed as an nmethod, memcpy it over (if it's static), or use the MacroAssembler if it's not.

That's an interesting idea and would be great if possible. However, given that Graal puts the slow path out-of-line, we'd be stuck with the problem of patching in the jump target. Also, JVMCI would have to conservatively emit a long-form jump instruction to the slow path.

[tkrodriguez]

It would be super nice if we could figure out a clean way to share canned snippets of assembly from HotSpot back through JVMCI. There are lots of potential complexities though: register usage, the jcc erratum, relocations, fast/slow splits. The emit function could be called from the Graal assembler so that the sizing and alignment can be properly handled. HotSpot relocations could be translated in some fashion and maybe labels could be handled as well.

The nmethod entry barrier fast path emission could probably be handled fairly cleanly since it's mostly a straightline snippet with a conditional branch at the end. It's just unclear if building that machinery is more complicated than maintaining and checking a clone of a small piece of assembly. The TestAssembler is a dubious piece of code given the complexity of emitting real nmethods. It doesn't even support the complex return sequence being used these days.

[dougxc]

The TestAssembler is a dubious piece of code given the complexity of emitting real nmethods. It doesn't even support the complex return sequence being used these days.

The next time there's a TestAssembler failure due to a change in nmethod invariants, I will remove it completely. There is sufficient coverage now in Graal tests that it no longer offers sufficient value.

[tkrodriguez]

Sounds and looks good.

[dougxc]

Thanks for the feedback and reviews.

/integrate

[openjdk]

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

• c1a1645: 8331655: ClassFile API ClassCastException with verbose output of certain class files
• 36c9607: 8331591: sun.font.CharSequenceCodePointIterator is buggy and unused
• b33096f: 8295153: java/util/Base64/TestEncodingDecodingLength.java ran out of memory
• cf2c80e: 8331582: Incorrect default Console provider comment
• 77b7122: 8312104: Update java man pages to include new security category in -XshowSettings
• 87bb66c: 8331569: G1: Rename G1HRPrinter to G1HeapRegionPrinter
• 37c2469: 8331633: Use MIN2 in bound_minus_alignment
• 1d083eb: 8331562: G1: Remove API to force allocation of new regions
• 9697bc3: 8331428: ubsan: JVM flag checking complains about MaxTenuringThresholdConstraintFunc, InitialTenuringThresholdConstraintFunc and AllocatePrefetchStepSizeConstraintFunc
• ce73fec: 8331048: G1: Prune rebuild candidates based on G1HeapWastePercent early
• ... and 51 more: https://git.openjdk.org/jdk/compare/4f529f8c232b4082aa4aa39766bcf42b09885ee4...master

Your commit was automatically rebased without conflicts.

[openjdk]

@dougxc Pushed as commit b20fa7b.

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

[dougxc]

The next time there's a TestAssembler failure due to a change in nmethod invariants, I will remove it completely. There is sufficient coverage now in Graal tests that it no longer offers sufficient value.

Happened again: https://bugs.openjdk.org/browse/JDK-8336242

I'll put up a PR to remove the problematic test.