I had to run jmap
in order to take heap dump of my process. but jvm
returned:
Unable to open socket file: target process not responding or HotSpot VM not loaded
The -F option can be used when the target process is not responding
So I used the -F
:
./jmap -F -dump:format=b,file=heap.bin 10330
Attaching to process ID 10331, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 24.51-b03
Dumping heap to heap.bin ...
-F
is allright for taking heap dump?jmap
vs. jmap -F
, as well as jstack
vs. jstack -F
use completely different mechanisms to communcate with the target JVM.
When run without -F
these tools use Dynamic Attach Mechanism. This works as follows.
Before connecting to Java process 1234, jmap
creates a file .attach_pid1234
at the working directory of the target process or at /tmp
.
Then jmap
sends SIGQUIT
to the target process. When JVM catches the signal and finds .attach_pid1234
, it starts AttachListener
thread.
AttachListener
thread creates UNIX domain socket /tmp/.java_pid1234
to listen to commands from external tools.
For security reasons when a connection (from jmap
) is accepted, JVM verifies that credentials of the socket peer are equal to euid
and egid
of JVM process. That's why jmap
will not work if run by different user (even by root).
jmap
connects to the socket, and sends dumpheap
command.
This command is read and executed by AttachListener
thread of the JVM. All output is sent back to the socket. Since the heap dump is made in-process directly by JVM, the operation is really fast. However, JVM can do this only at safepoints. If a safepoint cannot be reached (e.g. the process is hung, not responding, or a long GC is in progress), jmap
will timeout and fail.
Let's summarize the benefits and the drawbacks of Dynamic Attach.
Pros.
jmap
or jstack
to connect to any other version of JVM.Cons.
euid
/egid
) as the target JVM.-XX:+DisableAttachMechanism
.When run with -F
the tools switch to special mode that features HotSpot Serviceability Agent. In this mode the target process is frozen; the tools read its memory via OS debugging facilities, namely, ptrace
on Linux.
jmap -F
invokes PTRACE_ATTACH
on the target JVM. The target process is unconditionally suspended in response to SIGSTOP
signal.
The tool reads JVM memory using PTRACE_PEEKDATA
. ptrace
can read only one word at a time, so too many calls required to read the large heap of the target process. This is very and very slow.
The tool reconstructs JVM internal structures based on the knowledge of the particular JVM version. Since different versions of JVM have different memory layout, -F
mode works only if jmap
comes from the same JDK as the target Java process.
The tool creates heap dump itself and then resumes the target process.
Pros.
ptrace
works whenever OS-level privileges are enough. E.g. root
can dump processes of all other users.Cons.
jmap
tries to handle all special cases, sometimes it may happen that target JVM is not in a consistent state.Note
There is a faster way to take heap dumps in forced mode. First, create a coredump with gcore
, then run jmap
over the generated core file. See the related question.