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

[Roman Kennke]

On Mon, 27 Mar 2023 15:53:47 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Is anybody familiar with the academic literature on this topic? I am sure I am not the first person which has come up with this form of locking. Maybe we could use a name that refers to some academic paper?
>
>> @rkennke Question about ZGC and LockStack::contains(): how does this work with colored pointers? Don't we have to mask the color bits out somehow when comparing? E.g. using `ZAddress::offset()` ?
> 
> That would be a question for @fisk and/or @stefank. AFAIK, the color bits should be masked by ZGC barriers *before* the oops enter the synchronization subsystem. But I kinda suspect that we are somehow triggering a ZGC bug here. Maybe we require barriers when reading oops from the lock-stack too?

> > > @rkennke Question about ZGC and LockStack::contains(): how does this work with colored pointers? Don't we have to mask the color bits out somehow when comparing? E.g. using `ZAddress::offset()` ?
> > 
> > 
> > That would be a question for @fisk and/or @stefank. AFAIK, the color bits should be masked by ZGC barriers _before_ the oops enter the synchronization subsystem. But I kinda suspect that we are somehow triggering a ZGC bug here. Maybe we require barriers when reading oops from the lock-stack too?
> 
> Oops that are processed in Thread::oops_do should not have load barriers. Other oops should have load barriers.

Ok, good. The lockstack is processed in JavaThread::oops_do_no_frames() which is called from Thread::oops_do(). But help me here: I believe ZGC processes this stuff concurrently, right? So there might be a window where the lock-stack oops would be unprocessed. The lock-stack would not go under the stack-watermark machinery. And if some code (like JVMTI deadlock detection pause) inspects the lockstack, it might see invalid oops? Is that a plausible scenario, or am I missing something?

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

PR Comment: https://git.openjdk.org/jdk/pull/10907#issuecomment-1485550661