[RFR]: Per thread IO statistics in JFR

[Erik Gahlin]

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 
>> necessary, we could omit updating the counters unless JFR or our 
>> extended thread dumps are activated (which are the consumers of the 
>> counters).
>>
>> In any case, I would have assumed the costs for upcall + counter 
>> update to be insignificant compared to the IO calls. We should of 
>> course measure that.
>>
>> If you generally object upcalls into the libjvm for 
>> statistical/monitoring reasons, this would make matters on a number 
>> of fronts more complicated. For instance, it was discussed extending 
>> NMT coverage to the JDK - which is already in part reality at 
>> Unsafe.AllocateMemory - and this would have to be done with upcalls too.
>>
> There are many issues here that will need write-up and discussion, 
> maybe a JEP if discussions converge on a proposal to bring into the 
> main line as this is a significant change with implications for many 
> areas of the platform. It also potentially conflicts in direction with 
> some of the other projects in progress (particularly with Loom trying 
> to re-imagine threads, do you really want to collect I/O stats on a 
> per thread basis in the future???).
>
> As regards the points to instrument then I think we have to assume 
> that much of the native code that is targeted by the current webrev 
> will go away or change significantly in the future. We've been on that 
> path for some time, e.g. the zip area or the prototype to replace the 
> SocketImpl used for classic networking that eliminates a lot of the 
> native code touched in that area by the webrev. Once Panama is further 
> along then I assume we will want to make use of it in the core 
> libraries and at least initially replace the JNI methods that just 
> wrap syscalls today, and longer term more significant refactoring. My 
> point is that instrumenting native methods may not be the right 
> approach, instead maybe we should be look at instrumenting the I/O 
> paths at the java level as that will likely play better with the VM. 
> There is some support for collecting I/O stats in JFR today and maybe 
> someone working in that area can explain that a bit more and what the 
> issues are.
>

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

> It's impossible to tell from the mail with the webrev what has been 
> explored and not explored. It feels like early stages in a much large 
> project that will need a write up of prototypes before a direction can 
> be proposed.
>
> -Alan