JDK-8069149: jdk.internal.pref.Perf is unaware of the VM option UsePerfData
David Holmes
david.holmes at oracle.com
Fri Jun 1 01:16:09 UTC 2018
Hi Gary,
Meta-question partially raised in the the recent bug report comments: do
we care about this any more? Does anything need to disable UsePerfData?
Can we not deprecate it in 11 then obsolete in 12? That would be a lot
simpler.
That aside ...
It's hard to see how all the different paths in these related API's
stitch together - especially when you have to consider the API being
used on the current VM or a different one. I'm not at all clear what the
control flow is, so it is hard to see exactly how the initialization
issue is being handled. As I wrote in the initial report it is unclear
exactly which parts of the "perf" subsystem are impacted by the value of
UsePerfData.
Can you summarize the role of the is_initialized check versus a direct
UsePerfData check on the VM side i.e. which should be checked when? I
immediately see an issue that Perf_Detach is a no-op when !UsePerfdata,
yet Perf_Attach doesn't examine the flag at all! But perhaps we never
reach those methods because of a higher-level call filtering it out ??
More below ...
On 1/06/2018 5:09 AM, Gary Adams wrote:
> A patch was done previously to prevent an error when -XX:-UsePerfData
> is used, but this bug was filed to make the setting more visible in the
> jdk.internal.perf package.
>
> Webrev: http://cr.openjdk.java.net/~gadams/8069149/webrev.00/
> Issue: https://bugs.openjdk.java.net/browse/JDK-8069149
>
> I have tried a few initial tests using:
>
> make run-tests \
> TEST_OPTS=VM_OPTIONS=-XX:-UsePerfData \
> TEST=open/test/jdk/sun/management/jmxremote
>
> While I'm tracking down one test timeout, I'd like to get some
> feedback on the approach used here :
>
> - the basic mechanism propagates the "is initialized" state up to
> Perf.java;
Within PerfMemory UsePerfData and is_usable() are used for guarding
execution. Perhaps that is what needs to be propagated up?
> does the state need to be exposed to users getPerf(), or is it
> sufficient
> to provide exceptions at this level.
Unclear what the control flow is here. I don't see that Perf triggers
initialization of the perf subsystem, so what guarantees initialization
should have happened by the time the Perf class is initialized ??
> - an existing use of IOException was used in the case of attach
> failures;
> added IOExceptions to the createXXX methods if the memory was not
> initialized
On the VM side can you at least add a message to the IOException so that
the user can tell why it was thrown.
> - presuming a CSR would be needed to cover the IOExceptions
It's not a public API so no CSR should be needed.
> - it appears that jdk.internal.perf has very limited usage,
> is it still needed/used (?)
I can't answer that part, but I don't think UsePerfData is needed any more.
Thanks,
David
> Any feedback appreciated.
>
More information about the serviceability-dev
mailing list