RFR: 8245446: vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine/TestDescription.java crash intermittently

[Chris Plummer]

On Tue, 8 Dec 2020 09:53:36 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The StressRedefine.java (base for redefine stress tests) defines 3 important constants:
>     private static int staticMethodCallersNumber = 10;
>     private static int nonstaticMethodCallersNumber = 10;
>     private static int redefiningThreadsNumber = 40;
> 
> The 1st is number of threads to call a static method from constantly redefined class.
> The 2nd is number of threads to call am instance method from constantly redefined class.
> The 3rd is number of threads to redefine the target class.
> The redefiningThreadsNumber=40 is unreasonably big for the StressRedefine test, and there is no chance with -Xcomp  for one of the methods above to get resolved without a class redefinition. So, after 100 of non-successfull attempts we hit the guarantee in the open/src/hotspot/share/interpreter/interpreterRuntime.cpp:879
>   guarantee((retry_count++ < 100)) failed: Could not resolve to latest version of redefined method 
> To avoid it, the test StressRedefine/TestDescription.java is tweaked to have redefiningThreadsNumber=4.
> 
> The test StressRedefineWithoutBytecodeCorruption is worse as it fails even with redefiningThreadsNumber=1. So, a require is added to exclude the test with the -Xcomp flag.

Marked as reviewed by cjplummer (Reviewer).

test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine/TestDescription.java line 39:

> 37:  *      nsk.jvmti.RedefineClasses.StressRedefine
> 38:  *      ./bin
> 39:  *      -redefiningThreadsNumber 4

So `-redefiningThreadsNumber` has always been an allowed option to `StressRedefine`, yet this is the first time it's ever been used? Not an issue. Just a bit odd that the option was already there for you to use.

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

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