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
