RFR (M): 8231209: [REDO] ThreadMXBean::getThreadAllocatedBytes() can be quicker for self thread

Hohensee, Paul hohensee at amazon.com
Fri Sep 20 23:28:46 UTC 2019


java.lang.management.ThreadMXBean has two default methods that throw UnsupportedOperationException:

ThreadInfo[] getThreadInfo(long[], boolean, boolean, int)
ThreadInfo[] dumpAllThreads(boolean, boolean, int)

Without actually testing it, is it safe to assume that since com.sun.management.ThreadMXBean extends j.l.m.ThreadMXBean, the new c.s.m.ThreadMXBean method

    public default long getCurrentThreadAllocatedBytes() {
        throw new UnsupportedOperationException();
    }

will behave the same way?

Thanks,

Paul

On 9/20/19, 4:15 AM, "Daniel Fuchs" <daniel.fuchs at oracle.com> wrote:

    Hi Paul,
    
    It might be worth double checking what happens if you create a
    MXBean proxy to access the com.sun.management.ThreadMXBean
    in a remote server:
    
    https://download.java.net/java/early_access/jdk14/docs/api/java.management/java/lang/management/ManagementFactory.html#getPlatformMXBean(javax.management.MBeanServerConnection,java.lang.Class)
    
    and
    
    https://download.java.net/java/early_access/jdk14/docs/api/java.management/javax/management/MBeanServerInvocationHandler.html#newProxyInstance(javax.management.MBeanServerConnection,javax.management.ObjectName,java.lang.Class,boolean)
    
    are two different ways of doing this.
    
    Will getCurrentThreadAllocatedBytes() return something
    (however uninteresting that might be) or will the
    default implementation be triggered on the client side and
    UnsuportedOperationsException be thrown directly without
    invoking the server?
    Whatever the result is - it might be worth mentioning in the
    CSR.
    
    Best regards,
    
    -- daniel
    
    On 19/09/2019 17:39, Hohensee, Paul wrote:
    > Off by 2 error. Changed the subject to reflect 8231209.
    > 
    > http://cr.openjdk.java.net/~phh/8231209/webrev.00/
    > 
    > Paul
    



More information about the serviceability-dev mailing list