RFR: 8319797: Recursive lightweight locking: Runtime implementation [v4]

[David Holmes]

On Tue, 14 Nov 2023 22:25:34 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> In exit we must always check for recursions first. Unsure what you are proposing here.
>> 
>> Maybe you want to call remove first, and have a branch on if the number removed is greater than 1. And in that case inflate an update the recessions field before falling through. Something like this:
>> ```c++
>>       // Fast-locking does not use the 'lock' argument.
>>       LockStack& lock_stack = current->lock_stack();
>>       if (mark.is_fast_locked()) {
>>         if (lock_stack.try_recursive_exit(object)) {
>>           // Recursively unlocked.
>>           return;
>>         }
>> 
>>         size_t recursions = lock_stack.remove(object) - 1;
>> 
>>         if (recursions == 0) {
>>           while (mark.is_fast_locked()) {
>>               const markWord new_mark = mark.set_unlocked();
>>               const markWord old_mark = mark;
>>               mark = object->cas_set_mark(new_mark, old_mark);
>>               if (old_mark == mark) {
>>                 return;
>>               }
>>             }
>>         }
>> 
>>         lock_stack.push(object);
>>         ObjectMonitor* mon = inflate(current, object, inflate_cause_vm_internal);
>>         if (mon->is_owner_anonymous()) {
>>           mon->set_owner_from_anonymous(current);
>>         }
>>         mon->set_recursions(recursions);
>>       }
>> 
>> 
>> This make the code a little more like the emitted code. Except it is conditioned on the mark word lock bits.
>> Hard to believe this will have a measurable difference. But at least to me it is more noisy.
>
> It wasn't the recursions I was querying but the unstructured locking aspect.

To be clear, my concern is that for a simple exit we not only have to first check for a recursive exit (fine) but also this unexpected rare unstructured locking recursive case. Thinking it through part of the problem is that a simple-exit does itself allow for unstructured locking. Is it worth adding an additional case to peek at the top of the lock-stack and then do an exit with a pop for the most common non-recursive case? That way we in effect handle things as follows:
- recursive exit
- direct exit
- recursive unstructured exit
- direct unstructured exit

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16606#discussion_r1393397999