RFR: 8291555: Implement alternative fast-locking scheme [v30]

[Roman Kennke]

On Tue, 28 Mar 2023 02:56:47 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Ensure safepoint when processing lock-stack
>
> src/hotspot/share/runtime/lockStack.hpp line 43:
> 
>> 41:   // efficient addressing in generated code.
>> 42:   int _offset;
>> 43:   oop _base[CAPACITY];
> 
> Should we be using `OopHandle` here rather than raw oops? Would that not avoid issues with scanning the lock-stack only during safepoints?
> 
> Another alternative for a STW safepoint would be to do a handshake with the target threads.

I added verification of sane thread states (self, safepointed, handshaked, watermark-processing, suspended) when scanning the lock-stack. OopHandle would impact performance a bit too much for my taste. (If performance is not a prime concern, I would be happy to ditch stack-locking altogether and use monitors-only instead.)

Yes it might be useful if management code could handshake threads one-by-one instead of safepointing, but that's not within the scope of this PR, I think.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1153312238