JDK-8307970 : Thread.start is slow with large number of threads
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 17.0.7,21
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2023-05-12
  • Updated: 2024-09-20
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.
Other
tbdUnresolved
Related Reports
Relates :  
JDK-8340547 - Starting many threads can delay safepoints
Relates :  
JDK-8305670 - Performance regression in LockSupport.unpark with lots of idle threads
Description
We see a performance refression after migrating from JDK 8 to JDK 17/21. Similarly to JDK-8305670, the regression is related to Thread-SMR and a large number of background (idle) threads. Async-profiler shows the most time is spent in ThreadsSMRSupport::free_list called from JVM_StartThread - see attached JVM_StartThread.png.

I'm attaching the JMH benchmark that demonstrates the issue: ThreadStart.java

On JDK 8, the performance of Thread.start does not depend much on the number of threads:

Benchmark                (threadCount)  Mode  Cnt  Score   Error  Units
ThreadStart.threadStart              0  avgt    5  0.072 ± 0.006  ms/op
ThreadStart.threadStart           1000  avgt    5  0.073 ± 0.003  ms/op
ThreadStart.threadStart          10000  avgt    5  0.079 ± 0.007  ms/op
ThreadStart.threadStart          30000  avgt    5  0.088 ± 0.009  ms/op

However, on JDK 21, the latency of Thread.start degrades significantly with the number of idle threads:

Benchmark                (threadCount)  Mode  Cnt  Score   Error  Units
ThreadStart.threadStart              0  avgt    5  0.088 ± 0.002  ms/op
ThreadStart.threadStart           1000  avgt    5  0.111 ± 0.007  ms/op
ThreadStart.threadStart          10000  avgt    5  0.391 ± 0.024  ms/op
ThreadStart.threadStart          30000  avgt    5  0.828 ± 0.026  ms/op

The reason of a slowdown is a linear scan in ThreadsSMRSupport::free_list.