On Thu, 22 Apr 2021 15:08:59 GMT, Jaroslav Bachorik <jbacho...@openjdk.org>
wrote:
>> 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 != AbstractJDKEvent.class) {
>> 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.
>
> @egahlin Sounds good.
> Any particular reason you are using `Metrics[]` array?
> @jbachorik Has this been tested on cgroups v1 and cgroups v2 Linux systems?
OK. I've tested the latest iteration on both (cgroup v2 and cgroup v1). Testing
looks good other than the `memoryPressure` issue.
-------------
PR: https://git.openjdk.java.net/jdk/pull/3126
