RFR (M): 8207266: ThreadMXBean::getThreadAllocatedBytes() can be quicker for self thread

[Hohensee, Paul]

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