[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    Re: RFR 8075926: Add a sun.management.JMXConnectorServer perf counter to track its state
From:       Staffan Larsen <staffan.larsen () oracle ! com>
Date:       2015-05-19 17:46:17
Message-ID: 71F4EF1C-2298-4FA9-8ED5-BC94312F6FDF () oracle ! com
[Download RAW message or body]

Still good!

> On 19 maj 2015, at 15:35, Jaroslav Bachorik <jaroslav.bachorik@oracle.com> wrote:
> 
> On 19.5.2015 08:35, Staffan Larsen wrote:
> > Looks good!
> 
> Sorry Staffan, I forgot to include \
> test/sun/management/jmxremote/bootstrap/JvmstatCountersTest.java in the webrev :( 
> http://cr.openjdk.java.net/~jbachorik/8075926/webrev.02
> 
> -JB-
> 
> 
> > 
> > Thanks,
> > /Staffan
> > 
> > > On 18 maj 2015, at 19:23, Jaroslav Bachorik <jaroslav.bachorik@oracle.com> \
> > > wrote: 
> > > On 18.5.2015 10:41, Staffan Larsen wrote:
> > > > 
> > > > > On 18 maj 2015, at 10:25, Jaroslav Bachorik <jaroslav.bachorik@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();
> > > > }
> > > 
> > > Done. Please, see http://cr.openjdk.java.net/~jbachorik/8075926/webrev.01 for \
> > > the updated webrev. 
> > > -JB-
> > > 
> > > > 
> > > > /Staffan
> > > > 
> > > > > 
> > > > > -JB-
> > > > > 
> > > > > > 
> > > > > > Thanks,
> > > > > > /Staffan
> > > > > > 
> > > > > > > On 13 maj 2015, at 17:39, Jaroslav Bachorik \
> > > > > > > <jaroslav.bachorik@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-
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 


[prev in list] [next in list] [prev in thread] [next in thread]