RFR: 8203359: Container level resources events [v7]

[Erik Gahlin]

On Wed, 14 Apr 2021 08:28:37 GMT, Jaroslav Bachorik <jbachorik at openjdk.org> wrote:

>> 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.
>
> Right. So, for the initial drop I will just leave the container events registered unconditionally.

I think that is fine.

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

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