-
Type:
Enhancement
-
Resolution: Fixed
-
Priority:
P4
-
Affects Version/s: 26
-
Component/s: hotspot
-
b15
| Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
|---|---|---|---|---|---|---|
| JDK-8376201 | 25.0.3 | Johannes Bechberger | P4 | Resolved | Fixed | b01 |
Currently, the sampling queue size is unnecessarily large. For example, when running the Renaissance benchmark, most of the time the queue contains only one element. The current sizing of 500 (and higher for intervals < 10ms) wastes memory. But as a large queue size is still needed for worst-case benchmarks, I propose to start with a queue size of 20 and then scale it up if the queue overflows.
More information on my proposal can be found at: https://mostlynerdless.de/blog/2025/08/25/java-25s-new-cpu-time-profiler-queue-sizing-3/
More information on my proposal can be found at: https://mostlynerdless.de/blog/2025/08/25/java-25s-new-cpu-time-profiler-queue-sizing-3/
- backported by
-
JDK-8376201 Improve queue size computation in CPU-time sampler
-
- Resolved
-
- relates to
-
JDK-8367302 New test jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java from JDK-8366082 is failing
-
- Resolved
-
-
-
- Closed
-
- links to
-
Commit(master)
openjdk/jdk25u-dev/39733841
-
Commit(master)
openjdk/jdk/002f936e
-
Review(master)
openjdk/jdk25u-dev/44
-
Review(master)
openjdk/jdk/26926
(2 links to)