On Tue, 8 Dec 2020 21:01:07 GMT, Chris Plummer <cjplum...@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. > > 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. The StressRedefine class seems to be designed as a base for more advanced stress testing. My guess is there was a plan to add more test cases to it but it did not happen. ------------- PR: https://git.openjdk.java.net/jdk/pull/1692
