What interprocess communication mechanism is used by the Java Attach API?

Question

I am trying to find out the interprocess communication mechanism used by the Java Attach API on the main operating systems, but I can't seem to find much reference to the underlying mechanism.

The only mention I found was here where it refers to the DOORS interprocess communication mechanism developed some time ago by Sun. But I doubt this is used on Windows or Mac. Most of the articles describe the Java Attach API and how shared libraries / DLLs are loaded, but stop short of stating how communication between say jvisualvm and a local JVM process actually works.

Here there is a mention that tools.jar and libattach.so (on Unix systems) or attach.dll (on Windows) are responsible to support the Attach API, but I couldn't find much details of how they work internally.

So how does the interprocess communication for the Java Attach API work on each of the mainstream operating systems? That is, Windows, Mac OSX and Linux.

Vogeley

I believe you're looking for JPDA. – Larochelle

Well I want to know the actual underlying OS-level mechanism. For instance on linux does it used Unix Sockets? Does it use some other kernel mechanism? What about windows? – Vogeley

@ElliottFrisch thanks for the nudge in the right direction, I believe I found my answer docs.oracle.com/javase/8/docs/technotes/guides/jpda/… – Vogeley

Answer 1

The Java Attach API has a plugable provider architecture. The dynamic attach provider is specific for the target VM. In the case of Oracle or OpenJDK JVM the "sun" provider is responsible. This provider uses different methods, depending on the Operating System. The protocol also supports other serviceability tools (like jcmd commands)

For Linux it uses the following protocol:

• gather the pid of the target JVM and create a flagfile /tmp/.attach_pid%d
• send a SIGQUIT to the target JVM
• in the target JVM the signal handler will start the attach listener thread if the flag file exists.
• The attach listener thread will create a /tmp/.java_pid%d unix domain socket and listen on that socket for commands
• a typical command is load which tells the target JVM to load an agent implementation. This is implmented in the shared attachListener.cpp and loads a JVMTI agent.

The method used for JMX is "load" which loads a specified JVMTI agent and then connect regularly via RMI.

Older Java versions used java.io.tmpdir or even environemnt defined temporary directories, for later versions /tmp is however hardcoded.

On solaris a Door IPC instead of the unix domain socket is used. On windows a CreateRemoteThread with the name of a named pipe is used for this bootstrapping.

This is described here: http://openjdk.java.net/groups/hotspot/docs/Serviceability.html#tattach (I have not checked but I would expect the HP port to use the Linux mechanism, the OpenJDK AIX port does).

For IBM JDK a similiar mechanism (With more configuration) is used as documented here: https://www.ibm.com/support/knowledgecenter/en/SSYKE2_7.0.0/com.ibm.java.win.70.doc/user/attachapi.html

Joses

Just a BTW, above protocol does not work when the monitored JVM is in a container (different root and pid namespace). There is currently a patch going on to make the attach client use the root of the target and resolve PID namespaces. – Joses

Do you know what the status of this patch? Can you point me to resources relates to this? – Diameter

I was under the impression it is fixed for quite some time, but here is a bug about it which looks unresolved bugs.openjdk.java.net/browse/JDK-8228343 – Joses

Answer 2

Seems this is implemented on top of the Java Platform Debugger Architecture (JPDA) (as Elliott Frisch indicated).

On Windows OS, a Shared Memory transport is used.

On Linux based systems, a Socket transport is used.

More details can be found here.

Vogeley