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) 🔄 Re-review required (review applies to c3c92f53)
• Daniel Lundén (@dlunde - Committer)

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 is no longer ready for integration - check the PR body for details.

[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

• 01: Full - Incremental (0955e23d)
• 00: Full (c3c92f53)

[vnkozlov]

I agree with fix.

[dlunde]

Thanks for the fix @benoitmaillard!

This means that the safepoint will have top as data input, but this will
eventually cleaned up by the next round of IGVN.

Is it valid for safepoints to even temporarily have top as data input? Even if this gets cleaned up eventually by IGVN, it seems potentially risky to have it in this state.

[benoitmaillard]

Thanks for your review @dlunde. I would argue that this is acceptable, as we know the safepoint will be removed as soon as IGVN runs (since it is on a dead path). I see this as simply propagating dead path information and ensuring that it does not interfere with optimizing away the allocation.

[dlunde]

Thanks for your review @dlunde. I would argue that this is acceptable, as we know the safepoint will be removed as soon as IGVN runs (since it is on a dead path). I see this as simply propagating dead path information and ensuring that it does not interfere with optimizing away the allocation.

All right, seems harmless enough then. Thanks!

[benoitmaillard]

/integrate

[openjdk]

@benoitmaillard This pull request has not yet been marked as ready for integration.

[eme64]

You could make it more specific, and say what you say in your PR description:
return nullptr would lead to elimination bailout, but we want to prevent that. Just forwarding the top is also legal, and IGVN can just clean things up, and remove whatever receives top.

Does this mean that there could be paths that don't get top, and so for those paths it is nice that we are able to remove the allocation, right?