Hi Alan, On Thu, Jan 17, 2019 at 9:00 AM Alan Bateman <alan.bate...@oracle.com> 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???). > > 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? Thanks, Thomas > 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 >
