On Mon, 27 Mar 2023 15:53:47 GMT, Roman Kennke <rken...@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
