JDK-8340547 : Starting many threads can delay safepoints
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 24
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2024-09-20
  • Updated: 2024-10-14
  • Resolved: 2024-10-09
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 24
24 b19Fixed
Related Reports
Relates :  
JDK-8307970 - Thread.start is slow with large number of threads
Description
Starting a lot of threads in a burst can significantly delay safepoint synchronization, for example up to multiple seconds.

JVM_StartThread takes Threads_lock, and under that lock appends to the threads list for ThreadSMR support which can take ~0.1ms. If we have many concurrent calls to Thread.start, there can be an arbitrary number of callers waiting for the Threads_lock.

Safepoint synchronization also needs to acquire the Threads_lock before arming the safepoint, and it has no special priority so it can be arbitrarily delayed by JVM_StartThread calls.

The attached reproducer demonstrates the issue.

```
java -Xlog:safepoint -ThreadStartTtsp.java | grep -o 'Reaching safepoint: [0-9]* ns'
Reaching safepoint: 1291591 ns
Reaching safepoint: 59962 ns
Reaching safepoint: 1958065 ns
Reaching safepoint: 14456666258 ns <-- 14 seconds!
```
Comments
Changeset: e704c055 Branch: master Author: Oli Gillespie <ogillespie@openjdk.org> Date: 2024-10-09 15:28:44 +0000 URL: https://git.openjdk.org/jdk/commit/e704c055a4cf2aab77cc2b3d034f5a8b8d9e3331
09-10-2024
Moving to hotspot/runtime for initial triage.
20-09-2024
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/21111 Date: 2024-09-20 15:31:42 +0000
20-09-2024
JDK-8307970 shows that SMR makes thread creation expensive, which only makes this worse: not only we trash the Threads_lock, we can also hoard it enough -- for hundreds of microseconds -- so that VM Thread would be completely parked, and its wakeup would not get a good chance to acquire the lock before another Java thread manages to acquire it.
20-09-2024