[RFR]: Per thread IO statistics in JFR

[Alan Bateman]

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 also has concerns. I think it would be useful to start out 
with a summary of what the app server is looking to do with these stats. 
I think we need to understand if collecting by thread is really the 
right way to do this as it may not be the right approach in the long 
term. The granularity is also important as you've instrumented a bunch 
of places that are surprising as they aren't regular file or socket I/O. 
I think it's important to understand what prototypes were done with 
instrumentation at the java level rather than in the native methods. 
This goes to the maintenance concern. There were suggestions of 
performance issues but it's not clear if those experiments were recent 
or from 10 years ago. For the libraries area then we really should be 
reducing the native code for maintenance and debugging reasons, maybe 
performance reasons too once we can start to make use of Panama. Finally 
I think it's important to see how this fits with the instrumentation 
that JFR and other potential instrumentation of the libraries going 
forward (native method tracking was mentioned). So overall I think there 
is a lot to discuss and write-up.

-Alan