RFR: 8339725: Concurrent GC crashed due to GetMethodDeclaringClass [v13]

[Leonid Mesnik]

On Fri, 13 Sep 2024 05:44:44 GMT, Liang Mao <lmao at openjdk.org> wrote:

>> The fastdebug testing is very important for hotspot testing. Is it possible just to increase timeout so test pass with fastdebug? You can make 2 tests - 1 for product and 1 for fastdebug with different timeouts, if you want, but I would recommend just to increase the timeout. 
>> Also, please exclude test from tier1_serviceability in TEST.groups because it takes too many time for tier1.
>
> Fastdebug needs more than 30 minutes to finish and can hardly reproduce the crash. Do we still need that?

The 30 min is too much, however some testing in debug is better then nothing.
Can you add the test parameter "iterations" and set it to something reasonable .Then add test

/**
 * @test
 * @bug 8339725
 * @summary Stress test GetMethodDeclaringClass
 * @requires vm.jvmti
 * @requires (os.family == "linux")
 * @library /test/lib
 * @run driver/timeout=300 TestUnloadedClass <numb-of-iterations>
 */

and updat the check to

if (titerations == 0) {
  output.shouldContain("OutOfMemoryError");
}


So we have some testing in debug. The debug configurations are executed very often with different flags and still worth to run reduced testcase even if original bug is not reproduced. 
While the original testcase with no time/iteration limit is executed in product only.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20907#discussion_r1758983204