PS.
PerfCounter.java
lb field should be left as final. You can work around
definite-assignment problems by using a local variable and only
assigning to the field after the catch block:
private PerfCounter(String name, int type) {
this.name = name;
+ LongBuffer temp = null;
+ try {
ByteBuffer bb = perf.createLong(name, type, U_None, 0L);
bb.order(ByteOrder.nativeOrder());
+ temp = bb.asLongBuffer();
+ } catch (IOException e) {
+ // may not be available
+ }
+ this.lb = temp;
}
David
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;
does the state need to be exposed to users getPerf(), or is it
sufficient
to provide exceptions at this level.
- 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
- presuming a CSR would be needed to cover the IOExceptions
- it appears that jdk.internal.perf has very limited usage,
is it still needed/used (?)
Any feedback appreciated.
