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