> On 18 maj 2015, at 10:25, Jaroslav Bachorik <jaroslav.bacho...@oracle.com>
> wrote:
>
> On 18.5.2015 10:21, Staffan Larsen wrote:
>> Looks good, but why is the reverseBytes needed?
>>
>> 60 this.bb.asLongBuffer().put(Long.reverseBytes(l));
>
> For some reason Perf.createLong(...) will create bytebuffer with the HILO
> byte order reversed when compared to how long is usually represented.
I think you should set the order() of the ByteBuffer before you create the
LongBuffer. See the code in sun.misc.PerfCounter:
private PerfCounter(String name, int type) {
this.name = name;
ByteBuffer bb = perf.createLong(name, type, U_None, 0L);
bb.order(ByteOrder.nativeOrder());
this.lb = bb.asLongBuffer();
}
/Staffan
>
> -JB-
>
>>
>> Thanks,
>> /Staffan
>>
>>> On 13 maj 2015, at 17:39, Jaroslav Bachorik <jaroslav.bacho...@oracle.com>
>>> wrote:
>>>
>>> Please, review the following change
>>>
>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8075926
>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8075926/webrev.00
>>>
>>> The sun.management.JMXConnectorServer.<version>.<key> perf counters are not
>>> updated when the remote management agent is stopped.
>>>
>>> The perf counters show stale data and mislead the users.
>>>
>>> Since it is not possible to 'un-export' perf counters we need an additional
>>> counter tracking the version of the related perf counters in use.
>>>
>>> In the current implementation each start of the remote management agent
>>> will export a new set of the related perf counters
>>> (sun.management.JMXConnectorServer.<version>.<key>) with the <version> part
>>> increased by one. The first remote management agent start will use 0 as its
>>> version.
>>>
>>> The new counter 'sun.management.JMXConnectorServer.remote' will have value
>>> of -1 if the remote management is stopped and non-negative number
>>> corresponding to the version of the related perf counters in use.
>>>
>>> Thanks,
>>>
>>> -JB-
>>
>
