RFR(M): 8166554: Avoid compilation blocking in OverloadCompileQueueTest.java
Evgeny Nikitin
evgeny.nikitin at oracle.com
Mon Aug 31 20:22:03 UTC 2020
Hi,
Bug: https://bugs.openjdk.java.net/browse/JDK-8166554
Webrev: http://cr.openjdk.java.net/~enikitin//8166554/webrev.00/index.html
==== Problem explanation ====
The immediate reason for the test timeout is compilation lock within the
JVM during shutdown. In such a case, the VM gives the stuck compiler
threads 10 seconds to finish [0], after which shuts down not respecting
them. That 10 seconds of VM shutdown is enough for the test to fail in
some cases - the test is a stress test that utilizes almost all the
possible timeout[1].
The compilation lock, in its turn, is done via WhiteBox by the test. It
should gracefully unlock the compilation in the 'finally' block, but the
lockUnlocker thread is declared daemon[2], and therefore may not execute
the 'finally'.
==== Solution ====
Since the 'lockUnlock' is started via InfiniteLoop, it's not possible to
un-daemon it. So I just turned the lockUnlock method into a Thread
descendant, which got joined in the end. Not the most beautiful solution
given direct work with delays, but its main lock-unlock cycle is small
and it is clear about what it does.
Please review,
// Evgeny Nikitin.
========
[0]
http://hg.openjdk.java.net/jdk/jdk/file/6db0cb3893c5/src/hotspot/share/runtime/vmOperations.cpp#l388
[1]
http://hg.openjdk.java.net/jdk/jdk/file/e10f558e1df5/test/hotspot/jtreg/compiler/codecache/stress/CodeCacheStressRunner.java#l40
[2]
http://hg.openjdk.java.net/jdk/jdk/file/e10f558e1df5/test/hotspot/jtreg/compiler/codecache/stress/Helper.java#l59
More information about the hotspot-compiler-dev
mailing list