On Wed, 21 Apr 2021 13:34:28 GMT, Jaroslav Bachorik <jbacho...@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:
>
> Fix event metadata
I wonder if something similar to below could be added to jdk.jfr.internal.Utils:
private static Metrics[] metrics;
public static Metrics getMetrics() {
if (metrics == null) {
metrics = new Metrics[] { Metrics.systemMetrics() };
}
return metrics[0];
}
public static boolean shouldSkipBytecode(String eventName, Class<?>
superClass) {
if (superClass.getClassLoader() != null) {
return false;
}
if (!eventName.startsWith("jdk.Container")) {
return false;
}
return getMetrics() == null;
}
Then we could add checks to
jdk.jfr.internal.JVMUpcalls::bytesForEagerInstrumentation(...)
eventName = ei.getEventName();
if (Utils.shouldSkipBytecode(eventName, superClass))) {
return oldBytes;
}
and jdk.jfr.internal.JVMUpcalls:onRetransform(...)
if (jdk.internal.event.Event.class.isAssignableFrom(clazz) &&
!Modifier.isAbstract(clazz.getModifiers())) {
if (Utils.shouldSkipBytecode(clazz.getName(), clazz.getSuperclass())) {
return oldBytes;
}
This way we would not pay for generating bytecode for events in a non-container
environment.
Not sure if it works, but could perhaps make startup faster? We would still pay
for generating the event handlers during registration, but it's much trickier
to avoid since we need to store the event type somewhere.
-------------
PR: https://git.openjdk.java.net/jdk/pull/3126
