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 02:11:00 UTC 2021


On Tue, 2 Feb 2021 17:43:24 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Yang Yi has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.
>
> src/jdk.jfr/share/classes/jdk/jfr/internal/tool/Metadata.java line 213:
> 
>> 211:             if (file != null) {
>> 212:                 try (RecordingFile rf = new RecordingFile(file)) {
>> 213:                     types = rf.readEventTypes();
> 
> Maybe move this part into a separate method and remove the null check.
> 
> List<EventType> types = useEvenTypes(file);
> 
> private void useEventTypes(Path file) {
>     if (file == null) {
>        return new ArrayList<?>(FlightRecorder.getEventTypes());
>    }
>    try (RecordingFile rf = new RecordingFile(file)) {
>            return rf.readEventTypes();
>    } catch (IOException ioe) {
>         couldNotReadError(file, ioe);
>    }
> }

Fixed

> src/jdk.jfr/share/classes/jdk/jfr/internal/tool/Metadata.java line 225:
> 
>> 223:                 Collections.sort(types, new TypeComparator());
>> 224:             }
>> 225:             for (EventType type : types) {
> 
> This looks like a change of behavior, the metadata command no longer prints all the types, only event types.

`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.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1904


More information about the hotspot-jfr-dev mailing list