8362832: compiler/macronodes/TestTopInMacroElimination.java hits assert(false) failed: unexpected node

[benoitmaillard]

This PR prevents hitting an assert caused by encountering top while following the memory
slice associated with a field when eliminating allocations in macro node elimination. This situation
is the result of another elimination (boxing node elimination) that happened at the same
macro expansion iteration.

Analysis

The issue appears in the macro expansion phase. We have a nested synchronized block,
with the outer block synchronizing on new A() and the inner one on TestTopInMacroElimination.class.
In the inner synchronized block we have an Integer.valueOf call in a loop.

In PhaseMacroExpand::eliminate_boxing_node we are getting rid of the Integer.valueOf
call, as it is a non-escaping boxing node. After having eliminated the call,
PhaseMacroExpand::process_users_of_allocation takes care of the users of the removed node.
There, we replace usages of the fallthrough memory projection with top.

In the same macro expansion iteration, we later attempt to get rid of the new A() allocation
in PhaseMacroExpand::create_scalarized_object_description. There, we have to make
sure that all safepoints can still see the object fields as if the allocation was never deleted.
For this, we attempt to find the last value on the slice of each specific field (a
in this case). Because field a is never written to, and it is not explicitely initialized,
there is no Store associated to it and not even a dedicated memory slice (we end up
taking the Bot input on MergeMem nodes). By going up the memory chain, we eventually
encounter the MemBarReleaseLock whose input was set to top. This is where the assert
is hit.

Proposed Fix

In the end I opted for an analog fix as the similar JDK-8325030.
If we get top from scan_mem_chain in PhaseMacroExpand::value_from_mem, then we can safely
return top as well. This means that the safepoint will have top as data input, but this will
eventually cleaned up by the next round of IGVN.

Another (tempting) option would have been to simply return nullptr from PhaseMacroExpand::value_from_mem when encoutering top. However this would result in bailing
out from eliminating this allocation temporarily and effectively delaying it to a subsqequent
macro expansion round.

Testing

• GitHub Actions
• tier1-4, plus some internal testing

Thank you for reviewing!

---

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-8362832: compiler/macronodes/TestTopInMacroElimination.java hits assert(false) failed: unexpected node (Bug - P3)

Reviewers

• Vladimir Kozlov (@vnkozlov - Reviewer)

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 27903

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

Using diff file

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

Using Webrev

Link to Webrev Comment

[bridgekeeper]

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

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

8362832: compiler/macronodes/TestTopInMacroElimination.java hits assert(false) failed: unexpected node

Reviewed-by: kvn

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

• d55e1b4: 8370222: Wrong output for a command in jlink man page
• 9a88d7f: 8369211: AArch64: Devirtualize class RelocActions
• b77b910: 8369349: Add missing CPE headers
• ... and 152 more: https://git.openjdk.org/jdk/compare/fc49a1b502530908618b19bcd749aa4db0b598d9...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.

As you do not have Committer status in this project an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@vnkozlov) but any other Committer may sponsor as well.

➡️ To flag this PR as ready for integration with the above commit message, type /integrate in a new comment. (Afterwards, your sponsor types /sponsor in a new comment to perform the integration).

[openjdk]

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

• hotspot-compiler

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

• 00: Full (c3c92f53)

[vnkozlov]

I agree with fix.