JDK-8219999 : TestJFREvents container test should not use jdk.CPUInformation event for container CPU values
  • Type: Bug
  • Component: hotspot
  • Sub-Component: jfr
  • Affected Version: 13
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2019-03-01
  • Updated: 2024-06-04
  • Resolved: 2020-02-07
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 15
15 b10Fixed
Related Reports
Blocks :  
JDK-8203359 - Container level resources events
Relates :  
JDK-8214803 - Provide SQE and Infra support for 8203359 - container aware JFR events
Description
The event reports the number of CPUs based on host data, not the container data.
Comments
URL: https://hg.openjdk.java.net/jdk/jdk/rev/2d9610f6d9ac User: mseledtsov Date: 2020-02-07 21:04:30 +0000
07-02-2020
Here is the webrev: http://cr.openjdk.java.net/~mseledtsov/8219999.00/ I decided not to remove the test case, just to disable it and remove usage of jdk.CPUInformation. Once Container info events become available, this test case can be used/extended for testing CPU-related container configuration and info.
06-02-2020
After more discussions within JFR and Runtime team, we have decided on the following: - CPUInformation is intended to report hardware-based information, and should not be used to report OS or Container related information - the active_processor_count information should be reported in a Container-specific event, such as "Container Configuration" event proposed by "8203359: Create new events, and adjust existing events, to account for host/container reporting of resources" - the test TestJFREvents.java will be modified to not use CPUInformation.
06-02-2020
After some discussion current thought is to: - keep the meaning and function of jdk.CPUInformation "cores" field as is - introduce a new field for jdk.CPUInformation event that would return os::active_processor_count(), reflecting active processor count available to JVM, which is a container-aware value
06-02-2020