On Wed, 11 Nov 2020 20:33:15 GMT, Robbin Ehn <r...@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.
I like the fix. Taking Wicket out of play will help with class loading
issues in this test. You don't really need to deal with unexpected
locking events from the ObjectLocker usage by class loading.
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.
Perhaps:
// If we need to load any classes do execute doSleep(), do it now.
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.
-------------
Marked as reviewed by dcubed (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/1177
