Re: [RFR]: Per thread IO statistics in JFR

On 01/02/2019 10:52, Volker Simonis wrote: : As I wrote in my previous mail - this information has proved very valuable for both, our support engineers as well as our developers. What do you mean by "start with a summary"? The feature is trivial - you get exact, per thread IO information in the

RE: [RFR]: Per thread IO statistics in JFR

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

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

RE: [RFR]: Per thread IO statistics in JFR

Hi, > These features are orthogonal. Please read Gunter's answer about the > difference in his previous mail > (https://mail.openjdk.java.net/pipermail/core-libs-dev/2019- > January/058030.html) > repeated here for your convenience: > > "The existing events are triggered only if the time the IO

Re: [RFR]: Per thread IO statistics in JFR

On Wed, Jan 23, 2019 at 5:44 PM Alan Bateman wrote: > > On 23/01/2019 15:59, Haug, Gunter wrote: > > : > > > > As Volker writes, we still think that the overhead of the up-calls is > > acceptable but it would be possible to introduce a switch which is based on > > a system property. > > > There

Re: [RFR]: Per thread IO statistics in JFR

On 23/01/2019 15:59, Haug, Gunter wrote: : As Volker writes, we still think that the overhead of the up-calls is acceptable but it would be possible to introduce a switch which is based on a system property. There are concerns with the approach and patch. The replies from David hint that he

Re: [RFR]: Per thread IO statistics in JFR

Hi Alan, David Here are the results of the measurements. As mentioned before, I had measured some of the standard Java benchmarks and there was no impact. This is probably not surprising to anybody as the overhead up-calls is minuscule in comparison to the calculations that take place and is

Re: [RFR]: Per thread IO statistics in JFR

>Today we have File Read, File Write, Socket Read, and Socket Write > events. The hook points are added to the JDK using bytecode >instrumentation. This happens when you start a JFR recording, so there >is no overhead unless you use it. > >Erik However, in this context it's

Re: [RFR]: Per thread IO statistics in JFR

On Thu, Jan 17, 2019 at 1:31 PM Alan Bateman wrote: > > On 17/01/2019 07:23, Thomas Stüfe wrote: > > : > > > > Do you object against keeping these counters (which basically boils > > down to Thread::current->stat_structure->counter++)? Or do you even > > object against making upcalls into the

Re: [RFR]: Per thread IO statistics in JFR

Hi Alan, On Thu, Jan 17, 2019 at 9:00 AM Alan Bateman wrote: > On 17/01/2019 07:23, Thomas Stüfe wrote: > > : > > Do you object against keeping these counters (which basically boils down > to Thread::current->stat_structure->counter++)? Or do you even object > against making upcalls into the

Re: [RFR]: Per thread IO statistics in JFR

On 2019-01-17 09:00, Alan Bateman wrote: On 17/01/2019 07:23, Thomas Stüfe wrote: : Do you object against keeping these counters (which basically boils down to Thread::current->stat_structure->counter++)? Or do you even object against making upcalls into the jvm? Note that, if deemed

Re: [RFR]: Per thread IO statistics in JFR

On 17/01/2019 07:23, Thomas Stüfe wrote: : Do you object against keeping these counters (which basically boils down to Thread::current->stat_structure->counter++)? Or do you even object against making upcalls into the jvm? Note that, if deemed necessary, we could omit updating the counters

Re: [RFR]: Per thread IO statistics in JFR

On 17/01/2019 5:23 pm, Thomas Stüfe wrote: On Thu, Jan 17, 2019 at 1:23 AM David Holmes > wrote: On 17/01/2019 12:59 am, Alan Bateman wrote: > > Thanks for forwarding as this is a topic that will require a lot of > discussion and agreement

Re: [RFR]: Per thread IO statistics in JFR

On Thu, Jan 17, 2019 at 1:23 AM David Holmes wrote: > On 17/01/2019 12:59 am, Alan Bateman wrote: > > > > Thanks for forwarding as this is a topic that will require a lot of > > discussion and agreement from several areas due to potential impact on > > long term maintenance and the potential for

Re: [RFR]: Per thread IO statistics in JFR

On 17/01/2019 12:59 am, Alan Bateman wrote: Thanks for forwarding as this is a topic that will require a lot of discussion and agreement from several areas due to potential impact on long term maintenance and the potential for some of these native methods to go away. Gunter - can you

Re: [RFR]: Per thread IO statistics in JFR

Thanks for forwarding as this is a topic that will require a lot of discussion and agreement from several areas due to potential impact on long term maintenance and the potential for some of these native methods to go away. Gunter - can you summarize the approaches that you have explored?

Re: [RFR]: Per thread IO statistics in JFR

Hi Gunter, (I remove svc but add corelibs and hs-runtime for the jdk/hs parts, respectively. Hope this is not too spammy). This looks all very good. I am not a JFR reviewer (is there such a thing?) but only a JDK reviewer, so I am not sure if I am allowed to review the JFR parts. That said,