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. Hi Robbin, It isn't at all clear to me exactly what class initialization is happening, when, and how the contention is arising. I see in the bug report a stack dump for wicket.unlock and cannot see how unlock can trigger class initialization when all classes would have been needed by the lock. That aside avoiding the class loading/initialization seems more of a workaround. Ideally the test would be more discriminating about what monitors it checks for; or more accurately ensures that the code has reached the right place before doing the check. Thanks, David ------------- PR: https://git.openjdk.java.net/jdk/pull/1177
