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

[Erik Österlund]

On Mon, 27 Mar 2023 17:30:03 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> > > > @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?

The JVMTI deadlock detection runs in a safepoint, doesn't it? Safepoints call start_processing on all threads in safepoint cleanup for non-GC safepoints. That means the lock stack oops should have been processed when the deadlock detection logic runs in a safepoint.

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

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