[jdk17] RFR: 8268566: java/foreign/TestResourceScope.java timed out
This patch contains another minor tweak to TestResourceScope as we have seen this test timing out at least once (on arm64). I realized that some of the logic recently introduced in the test could lead to the test waiting forever: for instance, if all threads are executed right away before the main thread gets a chance to do anything, we'd be in a state where the lock count is zero, and no other thread will update it. I've removed the while loop - as that's not essential to make sure that the test works (what we want is to trigger a close operation that is concurrent with respect some acquire/release). I've also lowered the number of threads - which was using 10K - that was good for stress testing, but it's not a good number in more realistic conditions. ------------- Commit messages: - * Remove wait from test Changes: https://git.openjdk.java.net/jdk17/pull/45/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=45&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268566 Stats: 5 lines in 1 file changed: 0 ins; 4 del; 1 mod Patch: https://git.openjdk.java.net/jdk17/pull/45.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/45/head:pull/45 PR: https://git.openjdk.java.net/jdk17/pull/45
On Mon, 14 Jun 2021 15:42:03 GMT, Maurizio Cimadamore <mcimadamore@openjdk.org> wrote:
This patch contains another minor tweak to TestResourceScope as we have seen this test timing out at least once (on arm64).
I realized that some of the logic recently introduced in the test could lead to the test waiting forever: for instance, if all threads are executed right away before the main thread gets a chance to do anything, we'd be in a state where the lock count is zero, and no other thread will update it. I've removed the while loop - as that's not essential to make sure that the test works (what we want is to trigger a close operation that is concurrent with respect some acquire/release).
I've also lowered the number of threads - which was using 10K - that was good for stress testing, but it's not a good number in more realistic conditions.
LGTM ------------- Marked as reviewed by jvernee (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/45
On Mon, 14 Jun 2021 15:42:03 GMT, Maurizio Cimadamore <mcimadamore@openjdk.org> wrote:
This patch contains another minor tweak to TestResourceScope as we have seen this test timing out at least once (on arm64).
I realized that some of the logic recently introduced in the test could lead to the test waiting forever: for instance, if all threads are executed right away before the main thread gets a chance to do anything, we'd be in a state where the lock count is zero, and no other thread will update it. I've removed the while loop - as that's not essential to make sure that the test works (what we want is to trigger a close operation that is concurrent with respect some acquire/release).
I've also lowered the number of threads - which was using 10K - that was good for stress testing, but it's not a good number in more realistic conditions.
This pull request has now been integrated. Changeset: e3773977 Author: Maurizio Cimadamore <mcimadamore@openjdk.org> URL: https://git.openjdk.java.net/jdk17/commit/e3773977cfdcd691a5664a4715328f8552... Stats: 5 lines in 1 file changed: 0 ins; 4 del; 1 mod 8268566: java/foreign/TestResourceScope.java timed out Reviewed-by: jvernee ------------- PR: https://git.openjdk.java.net/jdk17/pull/45
participants (2)
-
Jorn Vernee
-
Maurizio Cimadamore