RFR: 8223498: Add Sum of Duration to the jfr summary command

[Erik Gahlin]

> On 8 May 2019, at 17:21, Chihiro Ito <chihiro.ito at oracle.com> wrote:
> 
> Until the jfr tool was created, the only way a user could see a jfr file was through JMC. Therefore, when a failure occurs, the user must open all JFRs in the JMC for viewing.
> Therefore, users want to be able to use the jfr tool to narrow down the jfr files they should see in the JMC. This allows users to see fewer jfr files using JMC.
> I have used JFR on a cluster of hundreds of Java processes, but it was very hard to see all the jfr files to figure out the cause.

Interesting use case. You want to search in a large set of files. Never thought of that.

I will keep that in mind going forward.


> 
> JMC had the ability to display the total duration, which was very useful.
> In my experience, I never use default.jfc or profile.jfc as is.

I think most people use the default configurations (default or profile).Very few would set the threshold to 0 ms for socket och synchronization events, The overhead would be too large. 


> All events indicating that threads cannot be used effectively should be logged without a threshold. I also limit the threads displayed in the JMC to those that are processed by the application.
> In such a situation, looking at the total duration is very useful for analyzing what is happening in the application. The application may be monitoring by code hidden in the library, or it may be sleeping a thread.

The purpose of the ‘summary' command was not provide a text based version of JMC, but to show low level information that is hard to get otherwise. 

For example how many bytes does an event use in a file? How much of a chunk consists of metadata or checkpoint data? What is the start time of a chunk? How many chunks are there in a file? What version of the file format is being used? You can not get that kind low level information using the API.

For a text based experience, I think it is better to create a new command that is much more powerful. Plan is to revisit this for a later JDK release.

For your specific use case, meanwhile, I would just use the API:

 public static void main(String... args) throws IOException {
        Map<String, Long> m = new TreeMap<>();
        for (var e : RecordingFile.readAllEvents(Path.of(args[0]))) {
            m.merge(e.getEventType().getName(), 0L, (a, b) -> b + e.getDuration().toNanos());
        }

        for (var h : m.entrySet()) {
            System.out.println(h.getKey() + " " + h.getValue());
        }
    }
}


> 
> I did not consider the 80 character limit. I think limiting the width is very useful for people to see. Instead of displaying nanosecond values, I will devise something.
> I'm very excited about future enhancements. It would be great if we could provide common requests as standard functions.

I imagine there would be a command to aggregate data similar to SQL query, but also predefined views that will show information for common scenarios, like ‘hot-methods’, ‘allocation-sites’ or ‘gc-info'. One such predefined view could be to show statistics per event type.

Regards
Erik


> 
> Regards,
> Chihiro
> 
> 
> 
> On 2019/05/08 22:55, Erik Gahlin wrote:
>> I don't see a benefit of adding a sum of duration column.
>> 
>> Events have thresholds. For example, the jdk.JavaMonitorWait event is only recorded if the event exceeds 20 ms so the sum would not be the actual sum. Also, things often happen in multiple threads which makes it hard to know what the value actually means.
>> 
>> The 'jfr' tool tries to not exceed 80 characters (to avoid wrapping), which is hard if another column is added. This especially true if user defined events are added with a longer namespace than "jdk."
>> 
>> The longer term plan is to add a more advanced command where users can aggregate data on arbitrary field and not just the sum as an aggregate function. Users would then be able to aggregate duration per event type, if they really wanted it.
>> 
>> Erik
>> 
>>> Hi,
>>> 
>>> Could you review this enhancement, please?
>>> 
>>> This enhancement adds the total duration of each event to the jfr summary command to help the user determine which events to display in the jfr output.
>>> 
>>> webrev:
>>> http://cr.openjdk.java.net/~cito/JDK-8223498/webrev.00/ <http://cr.openjdk.java.net/%7Ecito/JDK-8223498/webrev.00/>
>>> 
>>> jbs:
>>> https://bugs.openjdk.java.net/browse/JDK-8223498
>>> 
>>> I have passed the tests in test/jdk/jdk/jfr.
>>> 
>>> Best regards,
>>> Chihiro
>> 
>> 
>