Open fjeremic opened 4 years ago
@mpirvu could you give a short overview of how this CPU load value ends up being consumed in the JIT so that we know what we need to test once the change is made?
List of all the places where we use CPU information to drive heuristics in the JIT (in no particular order): 1) Don't downgrade to cold if the JIT is in IDLE state and it is already consuming very little CPU. This heuristic is not enabled by default because idle CPU could be used by other processes in a cloud scenario. 2) Detection of JIT compilation thread starvation needs to know how much CPU the JVM is consuming as well as how much CPU the JIT compilation threads are consuming and whether there are any idle cycles. 3) Serving compilation requests from the "low priority queue" is done only when there is idle time on the machine and when current JVM consumes less CPU than its allowed quota. 4) JVM phase is determined based on (among other things) the CPU it consumes.
Whoever picks up this item I'd appreciate if the above explanation was baked into the Doxygen documentation for this class.
The
CpuUtilization
class currently uses thej9sysinfo_get_CPU_utilization
API to extract the CPU utilization times for the entire system, and then uses these utilization times to calculate the CPU load based on the number of active cores.This is fine, except it does not work on z/OS, where there is no way to extract the CPU utilization times for the entire system. Instead we've delivered the
omrsysinfo_get_CPU_load
as part of eclipse/omr#4702 which returns the instantaneous CPU load for the entire system. On non-z/OS platforms it effectively utilizes thej9sysinfo_get_CPU_utilization
API and calculates the same value currently computed inCpuUtilization
, but on z/OS we query a system value which extracts the system CPU load.We should migrate to using the new API so we can support z/OS.
[1] https://github.com/eclipse/openj9/blob/14d688fb3f49e75e73a3155aa71cafea906ce076/runtime/compiler/env/CpuUtilization.cpp#L66