JDK-8331142 : Add test for number of loader threads in BasicDirectoryModel
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 23
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2024-04-25
  • Updated: 2024-11-12
  • Resolved: 2024-05-01
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 17 JDK 21 JDK 23 JDK 8
11.0.25-oracleFixed 17.0.13-oracleFixed 21.0.5-oracleFixed 23 b21Fixed 8u431Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Relates :  
Description
Add a test for JDK-8325179 which verifies the number of BasicDirectoryModel.FilesLoader background threads.

The test is heavily inspired by the test for BasicDirectoryModel, see JDK-8327137, and its code is based on the ConcurrentModification.java code.

The test captures snapshots of live threads and then counts the number of BasicDirectoryModel.FilesLoader threads in each snapshot.

There should be no more than two threads. There could be two BasicDirectoryModel.FilesLoader threads after the existing thread is interrupted but hasn't exited yet, and a new thread is already created.
Comments
[~andrewlu] The test is problem-listed by JDK-8337810, so you may want to include it into your backport. JDK-8337810 isn't backported to Oracle releases, I didn't see failures in Oracle CI, nor do I see them now.
06-11-2024

Fix request [17u] I backport this for parity with 17.0.13-oracle. No risk, only tests change. The test is limit to Windows, so backport with JDK-8331495 together, also backport with the new issue JDK-8331999 As https://bugs.openjdk.org/browse/JDK-8333880 not fixed, so this test may still fail. SAP nightly testing passed.
06-11-2024

A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk17u-dev/pull/2605 Date: 2024-06-18 08:02:55 +0000
31-10-2024

A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk11u-dev/pull/2789 Date: 2024-06-18 08:03:47 +0000
09-07-2024

A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk17u-dev/pull/2590 Date: 2024-06-14 09:41:11 +0000
09-07-2024

Fix request [21u] I backport this for parity with 21.0.5-oracle. No risk, only a test change. The test is limit to Windows, so backport with JDK-8331495 together. SAP nightly testing passed.
17-06-2024

[~andrewlu] You may take into account that there's another bug — JDK-8333880 — against this test which reports failures on Windows in 50% of cases. It was reported in comments of JDK-8331999. There have been no failures of BasicDirectoryModel/LoaderThreadCount.java in Oracle CI since I integrated JDK-8331999.
17-06-2024

A pull request was submitted for review. URL: https://git.openjdk.org/jdk11u-dev/pull/2778 Date: 2024-06-14 09:44:36 +0000
14-06-2024

A pull request was submitted for review. URL: https://git.openjdk.org/jdk21u-dev/pull/725 Date: 2024-06-14 09:36:27 +0000
14-06-2024

There are two follow-up fixes: • JDK-8331495: Limit BasicDirectoryModel/LoaderThreadCount.java to Windows only • JDK-8331999: BasicDirectoryModel/LoaderThreadCount.java frequently fails on Windows in CI The former makes the test run on Windows only, the latter improves its stability on Windows. There's a bug JDK-8331494 to make the test stable on Linux and macOS if possible.
24-05-2024

Fix request: 22u Provides a regression test for JDK-8325179. The backport is clean. Low risk. Pull request: https://github.com/openjdk/jdk22u/pull/175 Edit: If this is approved for 22u, JDK-8331495 needs to be approved too. The test proved to be unstable in CI on Linux and macOS. Thus, it's limited to Windows only.
01-05-2024

Changeset: b2fb5ea1 Author: Alexey Ivanov <aivanov@openjdk.org> Date: 2024-05-01 11:53:28 +0000 URL: https://git.openjdk.org/jdk/commit/b2fb5ea13ba5087411410519213fc953ecc44618
01-05-2024

A pull request was submitted for review. URL: https://git.openjdk.org/jdk22u/pull/175 Date: 2024-05-01 12:00:44 +0000
01-05-2024

A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/18957 Date: 2024-04-25 16:37:39 +0000
25-04-2024

Just like ConcurrentModification.java in JDK-8327137, the test creates a temporary directory in the current directory and creates a number of files in it. (The number of files is controlled by NUMBER_OF_THREADS constant). Then the test creates `JFileChooser` in the temporary directory. The test starts several scanner threads, the number is controlled by NUMBER_OF_THREADS, which repeatedly call `fileChooser.rescanCurrentDirectory()`. This results in calling `BasicDirectoryModel.validateFileCache` which starts a background thread — "Basic L&F File Loading Thread" — to enumerate the files. The test runner thread and scanner threads are synchronised with `CyclicBarrier`, this ensures all the scanner threads start at the same time. After a short delay, the runner thread takes a snapshot of live threads. After a longer delay, the operation is repeated. See the `getThreadSnapshot` method. (The number of snapshots is controlled by SNAPSHOTS constant.) The number of File Loading Threads in each snapshot is counted. There should be no more than two threads. It is possible that thread two such threads after JDK-8325179 is fixed: the existing thread is interrupted but hasn't exited yet, and a new thread is already created. The test fails consistently without the fix for JDK-8325179. With the fix, the test always passes.
25-04-2024