JDK-8268702 added:

// Since the DcmdFramework does not support dynamically allocated strings,
// we keep them in a thread local arena. The arena is reset between invocations.
static THREAD_LOCAL Arena* dcmd_arena = NULL;

...but that dcmd_arena is not cleared when thread dies.

 So if you run the workload like this:

import javax.management.MBeanServer;
import javax.management.ObjectName;

public class Leak {
  public static void main(String[] args) throws Throwable {
    ObjectName name = ObjectName.getInstance("com.sun.management:type=DiagnosticCommand");
    MBeanServer server = java.lang.management.ManagementFactory.getPlatformMBeanServer();
    while (true) {
      new Thread(() -> {
        try {
          server.getMBeanInfo(name);
        } catch (Throwable e) {
          e.printStackTrace();
        }
      }).start();
      Thread.sleep(1L);
    }
  }
}

...then there is a memory leak in:

//
//- Tracing (reserved=1089KB, committed=1089KB)
// (malloc=2KB #43)
// (arena=1087KB #34)
//--
//[0x0000000103c2f358] JfrDCmd::argument_info_array() const+0x1d0
//[0x0000000103ed3c38] jmm_GetDiagnosticCommandArgumentsInfo+0x134
//[0x00000001028e9c6c] getDiagnosticCommandArgumentInfoArray+0x78
//[0x00000001028ea0c4] Java_com_sun_management_internal_DiagnosticCommandImpl_getDiagnosticCommandInfo+0x198
// (malloc=2KB type=Tracing #34)

The relevant problem is that once the thread does this Dcmd only once, the arena is kept around even when not in use.

This was observed in the wild: the Prometheus scraper was getting the MBean info, and the delay between scraps was enough to get the new thread at every scrap, which exposed the memory leak.