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

Vladimir Kozlov kvn at openjdk.org
Wed Feb 14 22:08:03 UTC 2024


On Wed, 14 Feb 2024 19:38:01 GMT, Dean Long <dlong at openjdk.org> wrote:

> My concern is that a group of unbalanced locks is added to coarsened_locks (they have different BoxLockNodes), but later some of those locks are removed by `remove_useless_coarsened_locks` or `remove_coarsened_lock`. Then when `mark_unbalanced_boxes` finally runs, it incorrectly sees the group as balanced.
> 
> It is easy to check for unbalanced in `add_coarsened_locks` as the locks are added. I think this is the most conservative approach.

I think it is premature and too conservative.

If a locking region (related lock/unlock nodes with other BoxLockNode)  is removed because it is on dead path it can affect analysis of the rest of graph. I think it is normal. Yes, group could become balanced if nodes which are left points to the same BoxLockNode. I am not sure why it is the issue - the part of graph which made it unbalanced is gone before we check consistency, BoxLock marking and locks elimination.

That is why I am doing BoxLock nodes marking after verification of `locks_list` groups consistency and before we **actually** remove marked Lock/Unlock nodes from graph. At this point graph should be correct.

@iwanowww suggested that we can additionally verify in debug VM before eliminating coarsened Lock/Unlock nodes that information in `coarsened_locks` is correct: all paths from each Lock node have corresponding Unlock node which references same object and stack slot, but may be different BoxLock. We can do it as separate RFE.

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

PR Comment: https://git.openjdk.org/jdk/pull/17697#issuecomment-1944762459


More information about the hotspot-compiler-dev mailing list