-
Type:
Bug
-
Resolution: Fixed
-
Priority:
P3
-
Affects Version/s: 25
-
Component/s: hotspot
-
b07
| Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
|---|---|---|---|---|---|---|
| JDK-8362930 | 25.0.1 | Johannes Bechberger | P3 | Resolved | Fixed | b03 |
| JDK-8362253 | 25 | Johannes Bechberger | P3 | Resolved | Fixed | b32 |
This is related to the recomputation of the sampling interval whenever the environment changes and the user set a rate and not a specific interval directly.
To quote Andrei Pangin:
> If sampling period is configured as an absolute number in milliseconds, this value must be passed as is. Double conversion via Runtime.availableProcessors() / active_processor_count() is unobvious and error-prone. First, because of asymmetry: e.g. Runtime.availableProcessors() may be redefined by an agent so that its value is not aligned with active_processor_count(). Second, because number of available processors may change at runtime, e.g., by adjusting cgroup quotas.
This should be delt with.
To quote Andrei Pangin:
> If sampling period is configured as an absolute number in milliseconds, this value must be passed as is. Double conversion via Runtime.availableProcessors() / active_processor_count() is unobvious and error-prone. First, because of asymmetry: e.g. Runtime.availableProcessors() may be redefined by an agent so that its value is not aligned with active_processor_count(). Second, because number of available processors may change at runtime, e.g., by adjusting cgroup quotas.
This should be delt with.
- backported by
-
JDK-8362253 Fix interval recomputation in CPU Time Profiler
-
- Resolved
-
-
-
- Resolved
-
- relates to
-
JDK-8358666 [REDO] Implement JEP 509: JFR CPU-Time Profiling
-
- Resolved
-
-
-
- Closed
-
- links to
-
Commit(jdk25)
openjdk/jdk/a626c1d9
-
Commit(master)
openjdk/jdk/c70258ca
-
Review(jdk25)
openjdk/jdk/26313
-
Review(master)
openjdk/jdk/25775
(3 links to)