RFR: 8203359: Container level resources events [v10]
Jaroslav Bachorik
jbachorik at openjdk.java.net
Mon May 3 13:00:05 UTC 2021
On Mon, 26 Apr 2021 21:20:57 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:
>> Jaroslav Bachorik has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:
>>
>> - Prevent event container bytecode generation if no container present
>> - Fix event metadata
>> - Roll back conditional registration of container events
>> - Remove container events flag
>> - Remove trailing spaces
>> - Doh
>> - Report container type and register events conditionally
>> - Remove unused test files
>> - Initial test support for JFR container events
>> - Update the JFR control files
>> - ... and 3 more: https://git.openjdk.java.net/jdk/compare/c00a534f...04c3f092
>
> src/jdk.jfr/share/classes/jdk/jfr/internal/Utils.java line 729:
>
>> 727:
>> 728: public static boolean shouldSkipBytecode(String eventName, Class<?> superClass) {
>> 729: if (!superClass.getName().equals("jdk.jfr.events.AbstractJDKEvent")) {
>
> Was there a problem checking against the class instance? If so, perhaps you could add a check that the class is in the boot class loader (null).
Yes, `AbstractJDKEvent` is package private so it is not accessible from here.
> src/jdk.jfr/share/classes/jdk/jfr/internal/Utils.java line 737:
>
>> 735: private static Metrics getMetrics() {
>> 736: if (metrics == null) {
>> 737: metrics = Metrics.systemMetrics();
>
> Will this not lead to a lookup every time in an non-container environment?
Yes. Now I see why you used `Metrics[]` - will fix.
-------------
PR: https://git.openjdk.java.net/jdk/pull/3126
More information about the core-libs-dev
mailing list