RFR: 8260869: Test java/foreign/TestHandshake.java fails intermittently
This simple fix reduces the amount of concurrency on the foreign memory TestHandshake test. As this test spins a new accessor thread for each available processors, on machines which feature an high number of available processors (because of multi-threading), and which are slower in forking new threads (e.g. Windows), the test can sometimes timeout. The sensible step, for now, is to introduce an hard limit on the number of concurrent accessor threads being created. I've looked at the test logs quite in depth, and there's nothing suggesting that something else is amiss - the number of concurrent threads just seem to be too high in some instances. ------------- Commit messages: - Reduce concurrency in handshake test Changes: https://git.openjdk.java.net/jdk/pull/2748/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2748&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260869 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2748.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2748/head:pull/2748 PR: https://git.openjdk.java.net/jdk/pull/2748
On Fri, 26 Feb 2021 14:25:09 GMT, Maurizio Cimadamore <mcimadamore@openjdk.org> wrote:
This simple fix reduces the amount of concurrency on the foreign memory TestHandshake test. As this test spins a new accessor thread for each available processors, on machines which feature an high number of available processors (because of multi-threading), and which are slower in forking new threads (e.g. Windows), the test can sometimes timeout.
The sensible step, for now, is to introduce an hard limit on the number of concurrent accessor threads being created. I've looked at the test logs quite in depth, and there's nothing suggesting that something else is amiss - the number of concurrent threads just seem to be too high in some instances.
test/jdk/java/foreign/TestHandshake.java line 60:
58: 59: static final int NUM_ACCESSORS = Math.max(10, Runtime.getRuntime().availableProcessors()); 60:
`min` rather than `max` so as to clamp at a maximum of 10 accessors? ------------- PR: https://git.openjdk.java.net/jdk/pull/2748
On Fri, 26 Feb 2021 17:56:21 GMT, Paul Sandoz <psandoz@openjdk.org> wrote:
Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
Address review comments
test/jdk/java/foreign/TestHandshake.java line 60:
58: 59: static final int NUM_ACCESSORS = Math.max(10, Runtime.getRuntime().availableProcessors()); 60:
`min` rather than `max` so as to clamp at a maximum of 10 accessors?
Whoops - of course :-) ------------- PR: https://git.openjdk.java.net/jdk/pull/2748
This simple fix reduces the amount of concurrency on the foreign memory TestHandshake test. As this test spins a new accessor thread for each available processors, on machines which feature an high number of available processors (because of multi-threading), and which are slower in forking new threads (e.g. Windows), the test can sometimes timeout.
The sensible step, for now, is to introduce an hard limit on the number of concurrent accessor threads being created. I've looked at the test logs quite in depth, and there's nothing suggesting that something else is amiss - the number of concurrent threads just seem to be too high in some instances.
Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Address review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2748/files - new: https://git.openjdk.java.net/jdk/pull/2748/files/aa71dee6..df3346f5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2748&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2748&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2748.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2748/head:pull/2748 PR: https://git.openjdk.java.net/jdk/pull/2748
On Mon, 1 Mar 2021 19:30:00 GMT, Maurizio Cimadamore <mcimadamore@openjdk.org> wrote:
This simple fix reduces the amount of concurrency on the foreign memory TestHandshake test. As this test spins a new accessor thread for each available processors, on machines which feature an high number of available processors (because of multi-threading), and which are slower in forking new threads (e.g. Windows), the test can sometimes timeout.
The sensible step, for now, is to introduce an hard limit on the number of concurrent accessor threads being created. I've looked at the test logs quite in depth, and there's nothing suggesting that something else is amiss - the number of concurrent threads just seem to be too high in some instances.
Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
Address review comments
Marked as reviewed by psandoz (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2748
On Fri, 26 Feb 2021 14:25:09 GMT, Maurizio Cimadamore <mcimadamore@openjdk.org> wrote:
This simple fix reduces the amount of concurrency on the foreign memory TestHandshake test. As this test spins a new accessor thread for each available processors, on machines which feature an high number of available processors (because of multi-threading), and which are slower in forking new threads (e.g. Windows), the test can sometimes timeout.
The sensible step, for now, is to introduce an hard limit on the number of concurrent accessor threads being created. I've looked at the test logs quite in depth, and there's nothing suggesting that something else is amiss - the number of concurrent threads just seem to be too high in some instances.
This pull request has now been integrated. Changeset: 5de0f4b2 Author: Maurizio Cimadamore <mcimadamore@openjdk.org> URL: https://git.openjdk.java.net/jdk/commit/5de0f4b2 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod 8260869: Test java/foreign/TestHandshake.java fails intermittently Reviewed-by: psandoz ------------- PR: https://git.openjdk.java.net/jdk/pull/2748
participants (2)
-
Maurizio Cimadamore
-
Paul Sandoz