JDK-8069149: jdk.internal.pref.Perf is unaware of the VM option UsePerfData

[David Holmes]

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.
>