RFR: 8256156: JFR: Allow 'jfr' tool to show metadata without a recording [v7]
Yang Yi
github.com+5010047+kelthuzadx at openjdk.java.net
Wed Feb 3 08:28:43 UTC 2021
On Wed, 3 Feb 2021 05:43:34 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:
>> `FlightRecorder.getEventTypes()` only returns event types:
>> $ jfr metadata | grep ^class
>> class IntFlagChanged extends jdk.jfr.Event {
>> class JVMInformation extends jdk.jfr.Event {
>> class JavaErrorThrow extends jdk.jfr.Event {
>> ...
>> Should we use `jdk.jfr.internal.TypeLIbrary.getTypes()`? As you mentioned earlier, this would introduces the `jdk.jfr.internal` package, it returns all types:
>> $ jfr metadata dummy.jfr | grep ^class
>> class boolean {
>> class byte {
>> class char {
>> class double {
>> class float {
>> class int {
>> class long {
>> class short {
>> class Class {
>> class String {
>> class Thread {
>> class CalleeMethod {
>> class ClassLoader {
>> class BooleanFlag extends java.lang.annotation.Annotation {
>> class Category extends java.lang.annotation.Annotation {
>> class ContentType extends java.lang.annotation.Annotation {
>> class IntFlagChanged extends jdk.jfr.Event {
>> class JVMInformation extends jdk.jfr.Event {
>> class JavaErrorThrow extends jdk.jfr.Event {
>> ...
>> But as a drawback, we can not reuse existing category&event filter and related methods since they are only suitable for event types.
>
> The comment about FlightRecorder.getEventTypes() was on the test. If possible, I think we should avoid depending on internal packages in tests, as it makes them more fragile. Product code can depend on internal packages.
Changed.
-------------
PR: https://git.openjdk.java.net/jdk/pull/1904
More information about the hotspot-jfr-dev
mailing list