Can the test cases be broken into pieces or otherwise decomposed into several shorter-running tests? -Joe On 6/2/2021 2:35 PM, Maurizio Cimadamore wrote:

This patch increases time out for both TestUpcall and TestDowncall. These tests were already long-running, but with JEP-412, they were beefed up even more, so now they time out on some debug builds.

This patch also address a minor issue in TestResourceScope which can sometimes lead to intermittent failure, depending on how threads are scheduled.

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

Commit messages: - * Increase timeout for TestUpcall/Downcall

Changes: https://git.openjdk.java.net/jdk/pull/4321/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4321&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268131 Stats: 10 lines in 3 files changed: 7 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/4321.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4321/head:pull/4321

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

On Wed, 2 Jun 2021 21:20:53 GMT, Maurizio Cimadamore <mcimadamore@openjdk.org> wrote:

This patch increases time out for both TestUpcall and TestDowncall. These tests were already long-running, but with JEP-412, they were beefed up even more, so now they time out on some debug builds.

This patch also address a minor issue in TestResourceScope which can sometimes lead to intermittent failure, depending on how threads are scheduled.

Thumbs up. You might starting with 240 instead of 720 for the initial timeout bump. I would definitely prefer to have Tier4 quiet down for the upcoming code fork so increasing the timeout is good from my GK POV. These two tests were using the default timeout of 120 seconds/2 minutes and with a default timeoutFactor of 4 (set by the test task), the total timeout was 480 seconds/8 minutes. I recommend change the timeout from 720 to 240. That will give you a total timeout of 960 seconds/16 minutes. For the TestDowncall.java failure, that should cover that case. For the TestUpcall.java failure, we don't know if doubling the total timeout will cover that case or not because that test didn't pass while the timeout handler is running. However, doubling is a good start for a bump. Also, using a higher timeout value doesn't hurt anything if the test doesn't timeout. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4321

On Wed, 2 Jun 2021 21:20:53 GMT, Maurizio Cimadamore <mcimadamore@openjdk.org> wrote:

This patch increases time out for both TestUpcall and TestDowncall. These tests were already long-running, but with JEP-412, they were beefed up even more, so now they time out on some debug builds.

This patch also address a minor issue in TestResourceScope which can sometimes lead to intermittent failure, depending on how threads are scheduled.

I've adjusted timeout to 240, following suggestions - let's see what happens. ------------- PR: https://git.openjdk.java.net/jdk/pull/4321