On Wed, 21 Apr 2021 22:38:32 GMT, Erik Gahlin <[email protected]> wrote:
>> 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 != 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?
-------------
PR: https://git.openjdk.java.net/jdk/pull/3126