RFR: 8343840: Rewrite the ObjectMonitor lists

[Coleen Phillimore]

On Mon, 3 Feb 2025 16:29:25 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> I've combined two `ObjectMonitor`'s lists, `EntryList` and `cxq`, into one list. The `entry_list`.
> 
> This way c2 no longer has to check both `EntryList` and `cxq` in order to opt out if the "conceptual entry list" is empty, which also means that the constant question about if it's safe to first check the `EntryList` and then `cxq` will be a thing of the past.
> 
> In the current multi-queue design new threads where always added to the `cxq`, then `ObjectMonitor::exit` would choose a successor from the head of `EntryList`. When the `EntryList` was empty and `cxq` was not, `ObjectMonitor::exit` whould detached the singly linked `cxq` list, and add the elements to the doubly linked `EntryList`. The element that was first added to `cxq` whould be at the tail of the `EntryList`. This way you ended up working through the contending threads in LIFO-chunks.
> 
> The new list-design is as much a multi-queue as the current. Conceptually it can be looked upon as if the old singly linked `cxq` list doesn't end with a null pointer, but instead has a link that points to the head of the doubly linked `entry_list`.
> 
> You always add to the `entry_list` by Compare And Exchange to the head. The most common case is that you remove from the tail (the successor is chosen in strict FIFO order). The head is volatile, but the interior is stable.
> 
> The first contending thread that "pushes" itself onto `entry_list`, will be the last thread in the list. Each newly pushed thread in `entry_list` will be linked trough its next pointer, and have its prev pointer set to null, thus pushing new threads onto `entry_list` will form a singly linked list. The list is always in the right order (via the next-pointers) and is never moved to another list.
> 
> Since we choose the successor in FIFO order, the exiting thread needs to find the tail of the `entry_list`. This is done by walking from the `entry_list` head. While walking the list we assign the prev pointers of each thread, essentially forming a doubly linked list. The tail pointer is cached in `entry_list_tail` so that we don't need to walk from the `entry_list` head each time we need to find the tail (successor).
> 
> Performance wise the new design seems to be equal to the old design, even though c2 generates two less instructions per monitor unlock operation.
> 
> However the complexity of the source has been reduced by removing the `TS_CXQ` state and adding functions instead of inlining `cmpxchg` here and there, and the fact that c2 no longer has to check b...

src/hotspot/share/jvmci/vmStructs_jvmci.cpp line 332:

> 330:   volatile_nonstatic_field(ObjectMonitor,      _owner,                                        int64_t)                               \
> 331:   volatile_nonstatic_field(ObjectMonitor,      _recursions,                                   intptr_t)                              \
> 332:   volatile_nonstatic_field(ObjectMonitor,      _EntryListTail,                                ObjectWaiter*)                         \

You may need to coordinate with @mur47x111 to see what graal does with this field.  I suspect the graal code also checks both ctx and EntryList in the unlock fast path and now only needs to check _EntryList.  In which case we don't need to export EntryListTail.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23421#discussion_r1947058523