Hi Alan, Are you referring to this? 8148188: Enhance the security libraries to record events of interest http://hg.openjdk.java.net/jdk/jdk12/rev/f7309a1491d9
Which, presumably, needed this 8203629: Produce events in the JDK without a dependency on jdk.jfr http://hg.openjdk.java.net/jdk/jdk12/rev/a181612f0715?revcount=40 Best regards, Goetz. > -----Original Message----- > From: Alan Bateman <alan.bate...@oracle.com> > Sent: Freitag, 1. Februar 2019 12:37 > To: Lindenmaier, Goetz <goetz.lindenma...@sap.com> > Cc: hotspot-jfr-...@openjdk.java.net; Java Core Libs <core-libs- > d...@openjdk.java.net>; Hotspot dev runtime <hotspot-runtime- > d...@openjdk.java.net> > Subject: Re: [RFR]: Per thread IO statistics in JFR > > On 01/02/2019 11:19, Lindenmaier, Goetz wrote: > > : > > To kick in here, too: > > The existing solution tells you which threads spend a lot of time > > in IO operations. This is a good hint to problems in the infrastructure. > > You might just write a few bytes, but still get long delays because the > > disc is too slow or saturated etc. > > The numbers Gunter collects give information about what your > > code intends to do: how much bytes does the code write? Should > > you optimize your application to communicate less? ... to write > > less to file? > > > > If you have both numbers, you can even better recognize threads > > that wait too long on the network: they write few bytes but still > > spend a lot of time in the calls. > > > > So I see enough arguments to have both metrics. > > > Erik Gahlin put in support in JDK 12 to allow for code in java.base to > generate JFR events. I think the only user so far is in the security > area where there are events to log usages of weak crypto. I think this > is one of the approaches that will need to be looked at as part of the > exploration on the right way to add serviceability support to the libraries. > > -Alan
