RFR: 8193710 - jcmd -l and jps commands do not list Java processes running in Docker containers (original) (raw)

mandy chung mandy.chung at oracle.com
Thu Jan 18 00:49:26 UTC 2018

On 1/17/18 11:08 AM, Bob Vandette wrote:

I put these new methods in VMSupport since this was the class containg the getVMTemporaryDirectory and the intention of this class was document as:

/* * Support class used by JVMTI and VM attach mechanism. */ class VMSupport {

I looked at the history.  Initially VMSupport provides entry points for VM to call out.  VMSupport::serializePropertiesToByteArray and serializeAgentPropertiesToByteArray  are called by VM. VMSupport::getVMTemporaryDirectory was added in JDK 9 and all VMs use the same directory for all hsperfdata files.

The API is currently used by jdk.internal.jvmstat and jdk.management.agent.   But you may be right that when we decouple jdk.attach from jvmstat, jdk.attach may need to use this API (I don't know how it looks like yet).

I could create a new PerfDataFileImpl or jdk.internal.jvmstat.VMSupport class with a Linux specific alternate implementation that contains these classes:

getTemporaryDirectories getTemporaryDirectory getLocalVmId But the getNamespaceVmId method is also needed by the attach mechanism. I removed the duplicated functionality to avoid having to maintain this in 2 places.

Ah, it was in jdk.attach.

Shouldn’t the attach functionality, in the future, be decoupled from jvmstat? It looked like jcmd was using these jvmstat classes in order to avoid duplication but I don’t have all the history.

Yes and we attempted to eliminate the dependency from jdk.attach to jdk.internal.jvmstat but we haven't found a good way yet.  Since these new methods are implementation for attach and jvmstat, I personally prefer them to live there.   As for getNamespaceVmId, there is also a native implementation in VM.  I don't have a good suggestion.  Since it's a small utility, duplicating it for now may not be too bad and wait until attach and jvmstat are decoupled.

Mandy

More information about the core-libs-dev mailing list