RFR: 8255011: [TESTBUG] UnexpectedDeoptimizationAllTest.java timed out

[Igor Ignatyev]

On Tue, 3 Nov 2020 08:14:29 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

> Hi, 
> 
> This patch updates the code cache stress tests. I haven't been able to reproduce or retrieve a core file. 
> 
> What I can see is that the tests provokes compile storms, and that the single C1 thread (on a 4CPU system) sometimes has trouble keeping up. A factor may also be that the tests run time scale with the timeout time - so that the time allotted as margin before the timeout is only 20% of the total runtime. Combining this with Xcomp, and that the test may run concurrently with other stress tests, it is reasonable that a timeout may occur.
> 
> I suggest to cap the tests to 60 seconds of testing. I've experimented with meassuring how much work is done and use that as a metric - but the different tests that use the CodeCacheStressRunner has completely different profiles. 
> 
> In UnexpectedDeoptimizationAllTest.java I have adjusted the sleep time to 100 millis between the invalidations of the entire code cache.
> 
> In UnexpectedDeoptimizationTest.java  I have added a sleep of 10 miilis between deoptimizing parts of the stack. The idea is to give the stack time to growth a bit before the next deoptimization. Otherwise the test might end up running mostly in the interpreter.
> 
> Please review,
> Nils Eliasson

Changes requested by iignatyev (Reviewer).

test/hotspot/jtreg/compiler/codecache/stress/CodeCacheStressRunner.java line 45:

> 43:             long timeout = Utils.adjustTimeout(Utils.DEFAULT_TEST_TIMEOUT);
> 44:             timeout *= 0.75;
> 45:             new TimeLimitedRunner(timeout, 2.0d, this::test).call();

why do you need `end_time`? won't it be enough to just set `timeout` to 60_000?

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

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