RFR: 8324969: assert(false) failed: Non-balanced monitor enter/exit!

Vladimir Kozlov kvn at openjdk.org
Wed Feb 7 19:57:54 UTC 2024


On Wed, 7 Feb 2024 08:12:15 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

> Is the assumption here that each region has its own BoxLockNode, i.e. we have at most one lock and at most one unlock per box? Or can regions share a box? If it is shared: could we have an imbalance over multiple regions that share the BoxLock, but overall we have at least one lock and one unlock, and so we pass this test?

It is controlled by `EliminateNestedLocks` flag. By default the flag is ON and each synchronized region has its own BoxLockNode associated with it. The region can have one Lock node (before C2 transforms the graph) and multiple Unlock nodes (for each exit path). That is why I can't check matching numbers. I think it is possible to construct bytecode (jasm) with multiple Lock nodes for one region but in practice I never saw such case. W can have multiple Lock/Unlock nodes per region after C2 graph transformations (loop unroll/peelling) as in this case.

With `EliminateNestedLocks` flag switched off we don't do nested locks elimination and regions can share the same BoxLockNode node after Parse phase. We do only locks coarsening optimization and eliminate locks for not escaped objects.

> 
> Do I understand this right: returning false here just means that we don't do the optimization of removing the lock/unlock from the region? I think it is in `PhaseMacroExpand::mark_eliminated_box` that we would eliminate the box.

Actually the code which marks the box for nested locks is in `mark_eliminated_locking_nodes()` under `EliminateNestedLocks` flag. `is_nested_lock_region()` calls `is_simple_lock_region()` and will skip elimination for this case.

But yes, it also affects code in `mark_eliminated_box` which is called for locks with not-escaped objects. So we will not not eliminate those if we see not-balanced region (combined or not combined).

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

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


More information about the hotspot-compiler-dev mailing list