RFR: 8366694: Test JdbStopInNotificationThreadTest.java timed out after 60 second

[Chris Plummer]

On Tue, 2 Sep 2025 15:10:52 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> Test com/sun/jdi/JdbStopInNotificationThreadTest.java fails "Exception thrown during test execution: waitForPrompt timed out after 60 seconds" after JDK-8260555 change the default timeout factor from 4 to 1. Before JDK-8260555, the "waitForPrompt timed out" value if calculate from `Utils.adjustTimeout(60000)` in [test/jdk/com/sun/jdi/lib/jdb/Jdb.java](https://github.com/openjdk/jdk/blob/master/test/jdk/com/sun/jdi/lib/jdb/Jdb.java#L80), it will [multiply the timeout factor](https://github.com/openjdk/jdk/blob/master/test/lib/jdk/test/lib/Utils.java#L468) . After JDK-8260555 change the timeout factor from 4 to 1, so this timeout value should be ajusted.
> 
> Change has been verified locally, risk is low.

test/jdk/com/sun/jdi/lib/jdb/Jdb.java line 80:

> 78:     private static final long sleepTime = 1000;
> 79:     // max time to wait for  jdb output (in ms)
> 80:     private static final long timeout = Utils.adjustTimeout(120000);

The way this is implemented is unfortunate. Jdb responses should normally be fairly quick. However, in this test the response doesn't happen until 10% of the java heap has been allocated, and I guess that can be slow sometimes. For some reason the test only allocates 8k at a time, and does a 100ms sleep every 1000 allocations. So now because of this one test, all tests need an unnecessary long timeout. I'm not sure of the reason for the sleep, but in general my suggestion would be to speed up how quickly the test gets to the point of 10% of the java heap being in use.  I think using a smaller heap would be the best choice here. Updating the main method to the following should work:


    public static void main(String argv[]) {
        JdbTest test = new JdbStopInNotificationThreadTest();
        test.launchOptions.addVMOptions("-Xmx64m")
        test.run();
    }


Possibly 64m is too small. Remember the trigger happens at 10% of that size, so will happen when 6.4m is allocated. Hopefully that isn't until after the debuggee is actually into the memory allocation code and not before. You may need to adjust higher.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27055#discussion_r2316825591