On Wed, Jan 23, 2019 at 5:44 PM Alan Bateman <alan.bate...@oracle.com> 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 are concerns with the approach and patch. The replies from David > hint that he also has concerns.
David had concerns about the number of up-calls into the VM. If you've read Gunters last mail and looked at his performance numbers you can see that the proposed instrumentation has no measurable performance impact. So can we agree on the fact that the proposed solution doesn't introduce any performance issues? > 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. 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 same way you currently already get allocation information per thread. Why should the one be useful and the other not? > 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 me this is a strange argument. We propose a new feature and you ask us to implement a different feature and compare them. It's a little bit like somebody proposes a new GC and you reject it because there may be other GCs. > 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. I don't see Panama and the changes you envision arriving in the next one or two years. I therefore I don't see why we shouldn't be able to implement this feature now because eventually a feature which isn't nearly stabilized may interfere with it. And by the way, I still don't think that they will really interfere. The proposed change may change quite some places but the changes themselves are actually trivial. We could even make them smaller by using macros for example if that's something you think may help. In the end, I don't expect that maintaining this code will impose and fundamental problems. And I re-iterate that we're committed do that (in the same way we're already maintaining the PPC/AIX and s390 ports). > 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). 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 operation takes, exceeds a threshold (10ms/20ms for profile/default settings respectively). They are aimed for providing information on the time IO operations take and do not provide per thread IO statistics. What we are interested in is per thread information similar to the jdk.ThreadAllocationStatistics event." > So overall I think there > is a lot to discuss and write-up. > Sure, lets discuss this in Brussels at the Committers workshop :) Regards, Volker > -Alan
