On Wed, 11 Nov 2020 20:33:15 GMT, Robbin Ehn <[email protected]> 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 67:
> 65: public static int run(String argv[], PrintStream ref) {
> 66: out = ref;
> 67: 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.
-------------
PR: https://git.openjdk.java.net/jdk/pull/1177
