RFR: 8203359: Container level resources events [v7]

[Erik Gahlin]

On Fri, 2 Apr 2021 12:33:03 GMT, Jaroslav Bachorik <jbachorik at openjdk.org> wrote:

>> With this change it becomes possible to surface various cgroup level metrics (available via `jdk.internal.platform.Metrics`) as JFR events.
>> 
>> Only a subset of the metrics exposed by `jdk.internal.platform.Metrics` is turned into JFR events to start with.
>> * CPU related metrics
>> * Memory related metrics
>> * I/O related metrics
>> 
>> For each of those subsystems a configuration data will be emitted as well. The initial proposal is to emit the configuration data events at least once per chunk and the metrics values at 30 seconds interval. 
>> By using these values the emitted events seem to contain useful information without increasing overhead (the metrics values are read from `/proc` filesystem so that should not be done too frequently).
>
> Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove trailing spaces

src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JDKEvents.java line 163:

> 161:     private static void initializeContainerEvents() {
> 162:         containerMetrics = Container.metrics();
> 163:         if (containerMetrics != null) {

I understand this will reduce startup time, but it's contrary to how we treat other events. 

We register events, even if they can't be used. We want users to see what events are available (and their metadata) and use JMC recording wizard or other means to configure a .jfc file without actually being connected to a containerized process. We want the same events to minimize (subtle) platform dependent bugs.

I think we should try to find other means to reduce the startup time. It's better to have consistent behaviour, but an initial implementation than isn't as performant, than inconsistent behavior and somewhat faster implementation.

At some point we will need to address the startup cost of registering Java events anyway. For example, we could generate metadata at build time in a binary format, similar to what we already do with native events. Could even be the same file. Then we can have hundreds of Java events without the cost of reflection and unnecessary class loading at startup. We could add a simple check so that bytecode for the container events (commit() etc) are not generated unless in a container environment. A couple of (cached) checks in JVMUpcalls may be sufficient to prevent instrumentation cost.

src/jdk.jfr/share/conf/jfr/default.jfc line 1051:

> 1049:       <flag name="class-loading-enabled" label="Class Loading">false</flag>
> 1050: 
> 1051:       <flag name="container-events-enabled" label="Container Events">true</flag>

I don't think we should create "flag" for "Container Events". Instead we should treat them like CPU and other OS events, always on. Since JFR can be used outside a container, it seems wrong to have this as an option.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3126