On Wed, 14 Apr 2021 08:28:37 GMT, Jaroslav Bachorik <jbacho...@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