RFR: 8166554: Avoid compilation blocking in OverloadCompileQueueTest.java

[Aleksey Shipilev]

On Mon, 7 Sep 2020 09:59:40 GMT, Evgeny Nikitin <enikitin at openjdk.org> wrote:

> **Problem explanation**
> 
> 1. The stress test [uses 0.8 of allowed running
> time](https://hg.openjdk.java.net/jdk/jdk/file/e10f558e1df5/test/hotspot/jtreg/compiler/codecache/stress/CodeCacheStressRunner.java#l40)
> + 10 seconds, thus exceeding the limit; 2. 10 additional seconds are [given by the
> VM](https://hg.openjdk.java.net/jdk/jdk/file/6db0cb3893c5/src/hotspot/share/runtime/vmOperations.cpp#l388) for stuck
> compiler threads to finish; 3. Compiler threads aren't progressing due to the compilation being blocked; 4. Compilation
> is blocked via WhiteBox by the test, its lockUnlock thread; 5. The lockUnlock thread doesn't unblock the compilation
> because [it is a
> daemon](https://hg.openjdk.java.net/jdk/jdk/file/e10f558e1df5/test/hotspot/jtreg/compiler/codecache/stress/Helper.java#l59),
> it is stopped in the middle of the sleep.
> **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.

Looks good, modulo the minor issues.

test/hotspot/jtreg/compiler/codecache/stress/OverloadCompileQueueTest.java line 82:

> 80:
> 81: public class OverloadCompileQueueTest implements Runnable {
> 82:     private static final LockUnlockThread lockUnlockThread = new LockUnlockThread();

`static final` field should be `LOCK_UNLOCK_THREAD`?

test/hotspot/jtreg/compiler/codecache/stress/OverloadCompileQueueTest.java line 74:

> 72:             }
> 73:         } catch (InterruptedException e) {
> 74:             throw new Error("TESTBUG: lockUnlocker thread was unexpectedly interrupted", e);

Since `lockUnlocker` method is gone, the message should be "LockUnlockThread was unexpectedly interrupted"?

Also, throwing the error from this thread would not be rethrown with `join` later. If we care about this error, should
we instead store it into `static final` field here, check it after `join`, and rethrow if ` != null`. The old code
seems to have the same problem, though, so we can keep ignoring it.

test/hotspot/jtreg/compiler/codecache/stress/OverloadCompileQueueTest.java line 114:

> 112:
> 113:         lockUnlockThread.isActive = false;
> 114:         lockUnlockThread.join();

So this now relies on `lockUnlockThread` unblocking from its `Thread.sleep`-s, and then `joining` here? We could wait
here for up to `MAX_SLEEP` seconds then? Maybe we should command `lockUnlockThread.interrupt()` before `join()` to make
the test a tad faster?

-------------

PR: https://git.openjdk.java.net/jdk/pull/46