RFR: 8374721: containers/docker/ShareTmpDir.java timed out after 8362087

SendaoYan syan at openjdk.org
Wed Jan 7 14:03:21 UTC 2026


Hi all,

Sorry for the regression issue introduced by JDK-8362087. 

In the original code of JDK-8362087, before starting the first thread, a parameter was added to the global `DockerRunOptions` object, then the first Java thread was started, and within that thread, the first test Java process was launched. Immediately afterwards, a second parameter was added, and then a second Java thread was started, also launching a second test Java process. It was possible that when starting the second test Java process, the global `DockerRunOptions` object had already been assigned the second parameter, resulting in both test Java processes having identical parameters (two parameters each); whereas the original expectation was that the first Java process would have only one parameter, and the second would have two.

This PR fixed this bug. Adding the second parameter to the global `DockerRunOptions` object only after the first Java process has fully started ensures that both processes will have identical parameters.

Change has been verified locally on linux-x64 by run the test 100 times and all passed.

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

Commit messages:
 - 8374721: containers/docker/ShareTmpDir.java timed out after 8362087

Changes: https://git.openjdk.org/jdk/pull/29093/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29093&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8374721
  Stats: 8 lines in 1 file changed: 5 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/29093.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29093/head:pull/29093

PR: https://git.openjdk.org/jdk/pull/29093


More information about the hotspot-runtime-dev mailing list