How can I trigger a heap dump for a Java 7 VM running on Linux without having a JDK installed?
In earlier versions of Java it was possible to set the -XX:+HeapDumpOnCtrlBreak JVM option and then trigger a heap dump by using kill -QUIT <pid>. I have been unable to get this to work with Java 7. Is there an equivalent to this without needing the JDK installed to get JVisualVM or jmap.
VM option -XX:+HeapDumpOnCtrlBreak is no longer listed at http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html. So, I conclude that it's no longer supported.
From http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html:
Options that are specified with -XX are not stable and are subject to
change without notice.
You can generate a core dump with gcore, move it to another machine, and attach jmap to generate hprof file as described in Core dump taken with gcore, jmap conversion to hprof file format fails with Error message
See also accepted answer.
Related
I restarted a Java process with new memory options -Xms4G -Xmx4G -XX:MaxDirectMemorySize=6G and wanted to verify if these changes got correctly applied, especially the 6G of direct memory.
The first solution I found for verifying this was via java itself, but this simply reported a 0, implying that my new settings had no effect:
bash-4.4$ java -XX:+PrintFlagsFinal -version | grep MaxDirect
uintx MaxDirectMemorySize = 0 {product}
openjdk version "1.8.0_242"
OpenJDK Runtime Environment (build 1.8.0_242-b08)
OpenJDK 64-Bit Server VM (build 25.242-b08, mixed mode)
A second solution I found later was via jinfo, which apparently confirm the 6G that I indended to set:
bash-4.4$ jinfo -flag MaxDirectMemorySize 1
-XX:MaxDirectMemorySize=6442450944
I've relied on the java -XX:+PrintFlagsFinal for other purposes before, but now I wonder why it doesn't return the expected values. Why are java and jinfo returning different results?
There's (at least) two different JVMs.
[Expanding comment:] java {nothing} -XX:+PrintFlagsFinal -version creates a new JVM, changes none of its configuration from the default, and prints the resulting configuration, which is the default configuration with no changes -- and the default for MaxDirectMemSize is indeed zero.
OTOH jinfo {option} pid attaches to an existing already running JVM and obtains or changes the configuration of that JVM (although the specific pid 1 isn't usually a JVM but it often is in a docker container as you are using). jps lists the running JVMs you can attach to, with options to include JVM arguments and/or application arguments.
Does this imply that the same verification cannot be achieved with java? Unlike jinfo it cannot be attached to a running JVM?
Yes and no; it gets a bit Wonderlandy.
java by itself creates a new JVM, separate from any existing one. Normally this JVM runs a user-specified program, but with -version as you used it just prints version info and exits without running anything.
Now, the attach API is accessible from (and actually written partly in) Java. What jinfo does in more detail is:
create a new JVM; this doesn't use the java executable, so it isn't easily visible, but it actually is a JVM just like one from java
use that JVM to run some predefined Java code, which used to be in JDK/lib/tools.jar; I haven't bothered to track down where it is (and exactly how to access it) in the new post-8 modulated Java
that Java code when run in the jinfo JVM attaches to, and accesses information in, the specified other JVM, which was previously created and configured with java -Xvarious to run your application
You can actually do steps 2 and 3 yourself; you could write Java code that uses the API to attach to a specified (or otherwise located) existing JVM and get the info you want, and use java to run in JVM#2 your code that accesses info in existing JVM#1. But why bother, when jinfo (and jstat jmap jconsole etc) already does what is needed?
For that matter, jps also does this -- it runs its own JVM to run Java 'tool' code that uses the attach API to list JVMs. That's why the list produced by jps, unless filtered, includes jps itself. In fact, if you could run jps during the very short time jinfo is running, the jps list would include jinfo also -- and if you could determine the pid for jps and run jinfo on that pid during the very short time jps is running, you could get jinfo-type information on the jps JVM.
Clear enough?
I am using alloy4.2, and I am not able to tell it to use more memory.
I am not a Java expert and I suspect the problem is in how I'm configuring Java.
I am using OpenJDK Runtime Environment 1.8.0_131.
I have also tried 1.8.0_151.
My VM is running in Ubuntu x64.
Under the Alloy Options tab, Maximum Memory To Use is always stuck at the default of 768M.
I am using a VM that has 16G of memory available.
I have tried setting the Java stack parameters
-Xms1g and -Xmx8g
at the command line when I invoke Java, and also using the "export _JAVA_OPTS" to no avail.
Java says it is "picking up" the Xms and Xmx values and when I run
Java -XshowSettings:vm it shows that I have a max heap size of approx. 7.9G.
But Alloy doesn't let me increase the memory beyond the tiny minimum size of 768M. Any idea what I am doing wrong?
The numbers are hardcoded in Alloy although 4.2 should have 4Gb included? (There are a number of variants of 4.2 out there I think.)
We're working on creating a 5.0.0 version at the moment but that is not really publishable yet. You can download a snapshot JAR from:
https://oss.sonatype.org/content/repositories/snapshots/org/alloytools/org.alloytools.alloy.dist/5.0.0-SNAPSHOT/
I found Tool for analyzing java core dump, which is really close, but when I open up jvisualvm and open "File" menu, the "Add VM Coredump" option is not available. When I run the other option listed in the overflow article I don't get a thread dump. I'm digging into the jmap command a little farther, but I'd like to know how to use the Add VM Coredump feature as it would make life a bit easier.
You must be on Solaris or Linux to access the VisualVM Coredumps option.
In the documentation (http://visualvm.java.net/coredumps.html) it says:
The Core Dump node is visible in the Applications window if VisualVM is running on Solaris or Linux. Generally, VisualVM can only open a core dump if the core dump was taken on the same machine. A core dump contains informaton on the Java Development Kit (JDK) and kernel of the machine where the core dump was taken. To open the core dump in VisualVM, this information must match the JDK software and kernel of the local system.
Question
Why does VisualVM terminate my program when attempting to view object allocation stack trace, and how do I fix it?
I'm cleaning up an application which has a few memory problems, the biggest being creating a bunch of short-lived int[] which causes GC to fire like crazy:
When I right click int[] and choose Take Snapshot and Show Allocation Stack Traces, my application closes and a warning box pops up saying Failed to obtain results snapshot. The application terminated:
The closest thing I found on the subject was a bug report which recommended running my profiled application with -Xnoclassgc. It didn't work, the results were the same.
Specs
VisualVM: 1.8.0_60 (Build 1380-140910); platform 20140910-unknown-revn
Java: 1.8.0_60; Java HotSpot(TM) 64-Bit Server VM (25.60-b23, mixed mode)
Eclipse: Luna Release (4.4.0) Build id: 20140612-0600
System: Windows 7 (6.1) Service Pack 1, amd64 64bit
Crash log
http://pastebin.com/a4YPWutj
The size of the crash log exceeded the character limit, so I had to place it elsewhere. Sorry.
Ok. So based on the crashlog obtained, it looks like you ran into a VisualVM bug already reported here:
JVM being profiled crashes
The submitter of the original bug narrowed this behavior down to Java8, so the best chance you have is running a VisualVM on an older (Java7) runtime. If this is an option for you, then you only need to download a Java7 JDK and run the VisualVM directly from there.
According to documentation one could automatically take a heap dump when the application encounters an OutOfMemoryException.
After OutOfMemoryException process just disappear from left menu.
How does this feature works in VisualVM?
Thanks.
C:\work\temp>java -XX:HeapDumpPath=c:/work/temp/file.hprof -XX:+HeapDumpOnOutOfMemoryError -jar example.jar
As far as I know, that option in JVisualVM is equivalent to specifying -XX:+HeapDumpOnOutOfMemoryError as a JVM parameter. This causes the JVM to create a heap dump file when it encounters an OutOfMemoryError. This file can be then loaded into JVisualVM (or into a profiler) and analyzed there. The directory where the file is stored is defined by the -XX:HeapDumpPath parameter.
See also:
Troubleshooting Guide for Java SE 6 with HotSpot VM
Java HotSpot VM Options
StackOverflow: Using HeapDumpOnOutOfMemoryError parameter
Seems application just exited upon OOM. In this case, you must run your app with special -XX params. See "dump" params in JVM documentation. After application dies, you can examine dump in your tool.