RFR: 8324969: C2: prevent elimination of unbalanced coarsened locking regions [v7]

[Vladimir Kozlov]

On Mon, 26 Feb 2024 10:50:49 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

> Just out of curiosity: Do you often move out the limit from the loop?

Not always. Mostly when I have several usages or it is not constant. Here it is indirect load: [compile.hpp#L726](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/compile.hpp#L726)

> could you make mark_unbalanced_boxes const?

Yes, I can.

> For EliminateNestedLocks we now never have a hash, are only equal with this, and don't common nodes in Ideal either. Is that intended?

It was since JDK 8. I only corrected style there: added `{}`. And replaced `_is_eliminated` with accessor call.

It is intended for nested locks elimination - to have only one Object per locking region: [JDK-7125896 at locknode.cpp](https://github.com/openjdk/jdk/commit/94927c382b40c31f4525b0c71a64e34c26e03b98#diff-d38a64764056a8888cdffdfbbd8aa31cf00ddc96040bae83112521559a7fa0a6)

> Are there any IR tests that verify that we common nodes in the cases where we expect it to common?

These optimizations were implemented before we had IR tests. We have some regression tests. During my experiments I added `_kind` to `hash()` and a lot of tests in Tier1 (not just compiler) failed when ran with `-XX:-EliminateNestedLocks`:

#  Internal Error (/workspace/open/src/hotspot/share/opto/parse1.cpp:2030), pid=71294, tid=28931
#  assert(!nocreate) failed: Cannot build a phi for a block already parsed.

So we have this verification that we common these nodes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17697#discussion_r1503207411
PR Review Comment: https://git.openjdk.org/jdk/pull/17697#discussion_r1503237191