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

[Robbin Ehn]

On Wed, 11 Nov 2020 22:48:38 GMT, Daniel D. Daugherty <dcubed 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/contmon001.java line 79:
> 
>> 77:         contmon001a thr = new contmon001a();
>> 78:         startingBarrier = new Wicket();
>> 79:         waitingBarrier = new Wicket();
> 
> If you want to continue to use Wicket, then "all" you have to do is
> execute one back-and-forth of the Wicket before executing the
> test portion itself. That should get all the Wicket classes loaded
> before you really need them. Unless, of course, there's some class
> that isn't loaded unless there's an error or something...
> 
> However, by using volatile booleans instead, you get out of the
> game of trying to figure out how much of the Wicket code needs
> to be exercised to get everything you might need loaded.

We may load different classes depending on far in method waitFor we have reach before the unlock is called, on both sides.
So unlocked or waitFor may see a new class deeding on if are we added to queue, have we called the parker, etc..
Even if that is easy to figure out, if someone changes the Wicket or e.g. AbstractQueuedSynchronizer, the test may fail again.

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

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