JDK-8230311 : ThreadMXBean::getThreadAllocatedBytes() can be quicker for self thread
  • Type: CSR
  • Component: core-svc
  • Sub-Component: java.lang.management
  • Priority: P4
  • Status: Closed
  • Resolution: Approved
  • Fix Versions: 14
  • Submitted: 2019-08-28
  • Updated: 2019-09-19
  • Resolved: 2019-09-03
Related Reports
CSR :  
Description
Summary
-------

Add `com.sun.management.ThreadMXBean::getCurrentThreadAllocatedBytes`.

Problem
-------

com.sun.management.ThreadMXBean includes getThreadAllocatedBytes in two versions, one which takes a thread_id and another which takes an array of thread_ids.
```
getThreadAllocatedBytes(long id);
getThreadAllocatedBytes(long[] ids);
```
It also includes versions of getThreadCpuTime and getThreadUserTime that take an array of thread_ids.
```
getThreadCpuTime(long[] ids);
getThreadUserTime(long[] ids);
```
java.lang.thread.ThreadMXBean defines single thread_id and current thread versions of these.
```
getThreadCpuTime(long id);
getThreadUserTime(long id);
getCurrentThreadCpuTime();
getCurrentThreadUserTime();
```
Three versions of Cpu and User time are thus available from com.sun.management.ThreadMXBean: current thread, single thread_id, and an array of thread_ids. Only two versions of AllocatedBytes are currently available: single thread_id and an array of thread_ids.

The current thread versions of Cpu and User time are optimized to by avoiding checks needed by the versions that take thread_id(s). getCurrentThreadAllocatedBytes can also be so optimized, is useful for applications that monitor themselves, and rounds out the set of AllocatedBytes methods. As with the other AllocatedBytes methods, getCurrentThreadAllocatedBytes is a method on com.sun.management.ThreadMXBean rather than java.lang.thread.ThreadMXBean in order to avoid requiring all implementations to support it.

Solution
--------

Add `com.sun.management.ThreadMXBean::getCurrentThreadAllocatedBytes`.

Specification
-------------
```
/**
 * Returns an approximation of the total amount of memory, in bytes,
 * allocated in heap memory for the current thread.
 * The returned value is an approximation because some Java virtual machine
 * implementations may use object allocation mechanisms that result in a
 * delay between the time an object is allocated and the time its size is
 * recorded.
 *
 * <p>
 * This is a convenience method for local management use and is
 * equivalent to calling:
 * <blockquote><pre>
 *   {@link #getThreadAllocatedBytes getThreadAllocatedBytes}(Thread.currentThread().getId());
 * </pre></blockquote>
 *
 * @return an approximation of the total memory allocated, in bytes, in
 * heap memory for the current thread
 * if thread memory allocation measurement is enabled;
 * {@code -1} otherwise.
 *
 * @throws java.lang.UnsupportedOperationException if the Java virtual
 *         machine implementation does not support thread memory allocation
 *         measurement.
 *
 * @see #isThreadAllocatedMemorySupported
 * @see #isThreadAllocatedMemoryEnabled
 * @see #setThreadAllocatedMemoryEnabled
 * @since 14
 */
public long getCurrentThreadAllocatedBytes();
```



Comments
Since a changeset with the parent bug id has already been pushed, David's assessment on the need for a new bug is correct.
19-09-2019

This CSR and its associated issue are both resolved. A new CSR will need to be filed for the re-do issue.
19-09-2019

Right the platform MXBeans should become sealed types when we have the sealed type feature. [~darcy] should Paul withdraw this CSR and update it with the revised spec to make it a default method? Or file a new CSR as an amendment?
19-09-2019

I wasn't aware this was a `PlatformManagedObject` and so not intended to be implemented by any external classes - that fixes the compatibility issue. We still need to see why the tests are implementing this as it might be disallowed via sealed types in the future. Mandy suggested the default implementation should just throw `UnsupportedOperationException`.
19-09-2019

The compatibility risk section states: "Adds a method with well-understood semantics and leaves existing method semantics unchanged. Existing programs will continue to compile and execute as before. " but this adds a new method to a public interface, which means it will break all existing classes that implement that interface - as we have discovered now the change has been pushed. As a result the change is being backed out. The correct approach here would be to add a new default method to the interface, implemented as per the "is equivalent to calling" description.
19-09-2019

Moving to Approved.
03-09-2019