On Thu, 30 Mar 2023 11:45:54 GMT, Roman Kennke <rken...@openjdk.org> wrote:
>> I have another question about the asymmetric unlocking code in >> `InterpreterMacroAssembler::unlock_object`. >> >> We go through here for both fast-locked and fat OM locks, right? If so, >> shouldn't we do the asymmetric lock check only for the fast locked case? >> Otherwise Lockstack may be empty, so we compare the word preceding the first >> slot, which would cause us to always break into the slow case? >> >> Sorry if I miss something here. > >> I have another question about the asymmetric unlocking code in >> `InterpreterMacroAssembler::unlock_object`. >> >> We go through here for both fast-locked and fat OM locks, right? If so, >> shouldn't we do the asymmetric lock check only for the fast locked case? >> Otherwise Lockstack may be empty, so we compare the word preceding the first >> slot, which would cause us to always break into the slow case? >> >> Sorry if I miss something here. > > Uh, yes, indeed. It works by accident, I suppose, because we don't segfault > on the word preceding the lock-stack, and monitor-locking takes the slow-case > in interpreter, anyway. But yeah, it's better to check for it. > @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()` ? We must ensure that the oops are in a valid state. I recently added code to ::contains() to call start_processing() when called from a foreign thread. When inspecting its own thread, we are always good, because stack-watermark is processed right after leaving a safepoint, before resuming normal operations. ------------- PR Comment: https://git.openjdk.org/jdk/pull/10907#issuecomment-1490302961
