On Wed, 11 Nov 2020 22:33:57 GMT, Patricio Chilano Mateo
<pchilanom...@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
