[RFR]: Per thread IO statistics in JFR

[Haug, Gunter]

Hi Erik,

the overhead is very small. In fact, I wasn’t able to measure it in a reproduceable way. And yes, it works on Mac OS, I use a Mac.

> could change the contentType to "bits-per-second”. That is what we use for the Network Utilization event which reports statistics per interface.

Yes, I can do that. Only for the network IO or for file IO as well?

Thanks for looking into this,
Gunter

From: serviceability-dev <serviceability-dev-bounces at openjdk.java.net> on behalf of Erik Gahlin <erik.gahlin at oracle.com>
Date: Monday, 14. January 2019 at 22:32
To: "serviceability-dev at openjdk.java.net" <serviceability-dev at openjdk.java.net>, "hotspot-jfr-dev at openjdk.java.net" <hotspot-jfr-dev at openjdk.java.net>
Subject: Re: [RFR]: Per thread IO statistics in JFR

Hi Gunter, 

Sounds like a useful enhancement!

Do you have an idea of what the overhead might be? 

Does it work on Mac OS X?

I haven't done a proper review, but you could change the contentType to "bits-per-second”. That is what we use for the Network Utilization event which reports statistics per interface.

Thanks
Erik
Hi All,

Could I please have a review and possibly some opinions on the following enhancement to JFR and the JDK? 

At SAP we have a per thread IO statistic among our supportability enhancements which proved to be very helpful for our support engineers. It might be beneficial for JFR as well and would certainly help us to drive adoption of OpenJDK.

The basic idea is simple, we have added fields to the thread class where the number of bytes read and written from/to file and network are counted in. The newly created JFR events are written periodically as for example the ThreadAllocationStatistics event already is.

In order to collect the data, we have added hooks to the JDK C coding calling back into the VM.

I have opened a bug here:
https://bugs.openjdk.java.net/browse/JDK-8216981

Here is a webrev:
http://cr.openjdk.java.net/~ghaug/webrevs/8216981

There are no tests yet and the code be a bit nicer in places. We will work on this if/when this feature is deemed acceptable.

Finally, we have an API in our SAP version of the JDK to access this data from a Java application. This is used by many SAP applications and I think we could add an MXBean in a second step, to provide similar functionality.

Thanks in advance,
Gunter