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

List:       openjdk-serviceability-dev
Subject:    Re: RFR (M): 8207266: ThreadMXBean::getThreadAllocatedBytes() can be quicker for self thread
From:       "Daniel D. Daugherty" <daniel.daugherty () oracle ! com>
Date:       2019-09-19 13:31:05
Message-ID: 6924431f-87df-732b-43ac-2df931d384d2 () oracle ! com
[Download RAW message or body]

 > http://cr.openjdk.java.net/~phh/8231211/webrev.00/

The redo bug is 8231209. 8231211 is closed as a dup of 8231210.

Dan


On 9/19/19 9:17 AM, Hohensee, Paul wrote:
> I'll have the default method throw UOE. That's the same as the other default \
> methods do. 
> The necessary test fix is in \
> test/hotspot/jtreg/vmTestbase/nsk/monitoring/share/server/ServerThreadMXBeanNew.java, \
> which needs a new getCurrentThreadAllocatedBytes method, defined as 
> public long getCurrentThreadAllocatedBytes() {
> return (Long) invokeMethod("getCurrentThreadAllocatedBytes",
> new Object[] { },
> new String[] { });
> }
> 
> With this fix, the 134 tests in \
> test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadMXBean pass. Preliminary webrev \
> at 
> http://cr.openjdk.java.net/~phh/8231211/webrev.00/
> 
> Is it worth adding getCurrentThreadAllocatedBytes tests to the \
> test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadMXBean/GetThreadAllocatedBytes \
> set? 
> Paul
> 
> On 9/18/19, 8:16 PM, "David Holmes" <david.holmes@oracle.com> wrote:
> 
> On 19/09/2019 12:57 pm, Mandy Chung wrote:
> > On 9/18/19 5:00 PM, Hohensee, Paul wrote:
> > > They all implement com.sun.management.ThreadMXBean, so adding a
> > > getCurrentThreadAllocatedBytes broke them. Potential fix is to give it
> > > a default implementation, vis
> > > 
> > > public default long getCurrentThreadAllocatedBytes() {
> > > return -1;
> > > }
> > > 
> > 
> > com.sun.management.ThreadMXBean (and other platform MXBeans) is a
> > "sealed" interface which should only be implemented by JDK.
> 
> Didn't realize that. I don't recall knowing about PlatformManagedObject.
> Sealed types will at least allow this to be enforced, though I have to
> wonder what the tests are doing here.
> 
> > Unfortunately we don't have the sealed type feature yet.  Yes it needs
> > to be a default method.  I think it should throw UOE.
> > 
> > * @implSpec
> > * The default implementation throws {@code
> > UnsupportedOperationException}.
> > 
> > The @throw UOE can make it clear that it does not support current thread
> > memory allocation measurement.
> 
> Yes that seems a reasonable default if we don't want this to be
> implemented outside the platform.
> 
> Thanks,
> David
> 
> > Mandy
> 
> 


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