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-boun...@openjdk.java.net> on behalf of Erik Gahlin <erik.gah...@oracle.com> Date: Monday, 14. January 2019 at 22:32 To: "serviceability-dev@openjdk.java.net" <serviceability-dev@openjdk.java.net>, "hotspot-jfr-...@openjdk.java.net" <hotspot-jfr-...@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
