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