RFR: 8244679: JVM/TI GetCurrentContendedMonitor/contmon001 failed due to "(IsSameObject#3) unexpected monitor object: 0x000000562336DBA8"

Daniel D.Daugherty dcubed at openjdk.java.net
Wed Nov 11 22:57:59 UTC 2020


On Wed, 11 Nov 2020 22:33:57 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> As the stack trace in the bug shows, we cannot load classes, since we may take a monitor.
>> Resulting in an unexpected result to GetCurrentContendedMonitor().
>> Trying to use some decent primitive, e.g. Wicket/Semaphore/.., without being implementation dependent means we must warm up every possible scenario, since it may use a new class.
>> Instead I here just use sleep + volatile for the barriers.
>> 
>> I cannot reproduce with these changes.
>> 
>> Chewing through T6 as most issues have been seen there.
>
> test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetCurrentContendedMonitor/contmon002.java line 61:
> 
>> 59: 
>> 60:     public static int run(String argv[], PrintStream ref) {
>> 61:         doSleep(); // If it would do any class loading, do it now.
> 
> I think now the spawned thread should not try to resolve any new methods after setting the boolean so we shouldn't have the same ObjectLocker issue.

Perhaps:
// If we need to load any classes do execute doSleep(), do it now.

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

PR: https://git.openjdk.java.net/jdk/pull/1177


More information about the serviceability-dev mailing list