[jdk18] RFR: 8273107: RunThese24H times out with "java.lang.management.ThreadInfo.getLockName()" is null [v3]

[Erik Österlund]

On Thu, 16 Dec 2021 06:44:03 GMT, Erik Österlund <eosterlund at openjdk.org> wrote:

>> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   coleenp CR - cleanup type safety
>
> Looks okay, but I found a potential issue.

> I made changes to address @fisk's review. I've also included comment
> 
> updates to make clear the limitations of monitors_iterate(). I need a
> 
> re-review from @fisk and a re-review from @coleenp would also be
> 
> a nice thing to have. Thanks, in advance, for the re-review(s)...
> 
> 
> 
> Tested this latest patch with Mach5 Tier1. Mach5 Tier[23] are running now.
> 
> 
> 
> Update: Mach5 Tier[1-5] look good.

When the owner field of an ObjectMonitor is the address of a stack lock instead of a thread, it doesn't mean that it is a stack lock. It means that it *was* a stack lock when it was acquired by that thread, but has since then been upgraded to a full ObjectMonitor (by another thread), due to contention. But the fact that it *was* a stack lock is irrelevant in this context; we care about what it is now. And it is an inflated lock that just happens to have a slightly obscured owner field, as the owner thread was not easily available when it was inflated.

In other words, I still believe this is a bug. Such a monitor that gets upgraded from a stack lock to a full ObjectMonitor, can - unline actual stack locks - be involved in a deadlock that we are trying to find. If we don't associate such ObjectMonitor objects with its owner thread, then we will not be able to find the deadlock as we are supposed to with this code.

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

PR: https://git.openjdk.java.net/jdk18/pull/25