On Wed, 14 Apr 2021 08:28:37 GMT, Jaroslav Bachorik <[email protected]>
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
