[RFR]: Per thread IO statistics in JFR
thomas.stuefe at gmail.com
Thu Jan 17 15:40:17 UTC 2019
On Thu, Jan 17, 2019 at 9:00 AM Alan Bateman <Alan.Bateman at oracle.com>
> 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
I think we are aiming for something pragmatic which works right now, with
traditional threads, since per-thread IO is a really interesting statistic
in App server contexts.
> 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.
I understand your concerns, thank you for explaining. I have not followed
Panama that closely. I had a closer look today and like it, it looks
promising and does address a number of real pain points. Sorry for not
being up to date.
So, your long term goal is to get rid of all native JDK libraries, move all
that - partly highly platform dependent - coding up to java and just do
downcalls to naked, unadorned system APIs via something like Pinvoke? And
your argument is that it makes not much sense to put a lot of work into the
native JDK layer since it will vanish long term?
> 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
More information about the core-libs-dev