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

[Nils Eliasson]

On Wed, 4 Nov 2020 15:49:22 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

>> @neliasso ,
>> 
>> could you please explain why in `UnexpectedDeoptimizationAllTest` you "have adjusted the sleep time to 100 millis between the invalidations of the entire code cache"?
>
>> @neliasso ,
>> 
>> could you please explain why in `UnexpectedDeoptimizationAllTest` you "have adjusted the sleep time to 100 millis between the invalidations of the entire code cache"?
> 
> I was experimenting with different levels of contention. 10 millis + Xcomp gets 30% fewer methods compiled, but in all other cases 10 millis results in more compilations. It's a toss for me. 
> 
> I reverted since it doesn't really matter.

> @neliasso, could you please explain how those compile storms cause timeouts? As far as I could find, the JVM doesn't wait for the threads to finish, it gives them approx. [10 seconds](http://hg.openjdk.java.net/jdk/jdk/file/ee1d592a9f53/src/hotspot/share/runtime/vmOperations.cpp#l388), and then just [exits](http://hg.openjdk.java.net/jdk/jdk/file/ee1d592a9f53/src/hotspot/share/runtime/vmOperations.cpp#l424).

I don't know exactly since 1) I can't reproduce it 2) I didn't get any core or thread dump from the failure.

What I do know is 1) The failure was on a slow platform 2) It was probably running concurrently with other tests 3) It was running with -Xcomp

Using JFR and jcmd I have seen - 1) very long compile queues (> 500 for C1)

I did some measurements on workload too. In normal mode 6500 iterations of CodeCacheStressRunner was performed in 30 sec, with -Xcomp only 250. But in total compiles -Xcomp had 30% less compilations.

What I also do know is that the CodeCache lock will be contended by the compile threads and the test thread that is invalidating everything in the cache. With long compile queues the MethodCompileQueue lock can also become contented because the time held is proportional to the number of compile tasks in the queue. In register_method both locks are held.

> 
> So we only have to make sure that our 20% is larger than 10s + some reasonable margin, right?
>

Yes. I suggest 60 seconds test time and minimum of 60 seconds margin. 
I also suggest to not scale the test time with the timeout fraction since the run times becomes excessive. I experimented with keeping the CodeCaceStressRunner iterations constant but the different tests have completely different profiles and the variants are too many. 60 seconds is still a huge amount of compiles and invalidations. (times 2 since all tests are run with and without segmented code cache).

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

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