On Mon, 27 Mar 2023 17:30:03 GMT, Roman Kennke <rken...@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
