JVM has provided helpful arguments to deal with OutOfMemoryError. In this article, we would like to highlight those JVM arguments. It might come handy for you when you are troubleshooting OutOfMemoryError. Those JVM arguments are:
- -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath
- -XX:OnOutOfMemoryError
- -XX:+ExitOnOutOfMemoryError
- -XX:+CrashOnOutOfMemoryError
Let’s discuss these JVM arguments in detail in this article.
(1). -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath
Heap dump is basically a snapshot of memory. It contains details about objects that present in memory, actual data that is present within those objects, references originating of those objects. Heap dump is a vital artifact to troubleshoot memory problems.
In order to diagnose OutOfMemoryError or any memory related problem, one would have to capture heap dump right at the moment or few moments before the application starts to experience OutOfMemoryError. It’s hard to do capture heap dump at the right moment manually because we will not know when OutOfMemoryError is going to be thrown. However, capturing heap dumps can be automated by passing following JVM arguments when you launch the application in the command line:
-XX:+HeapDumpOnOutOfMemoryError and -XX:HeapDumpPath={HEAP-DUMP-FILE-PATH}Example:
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/crashes/my-heap-dump.hprof
In ‘-XX:HeapDumpPath’ you need to specify the filepath where heap dump should be stored.
When you pass these two JVM arguments, heap dumps will be automatically captured and written to the specified file path, when OutOfMemoryError is thrown.
Once heap dumps are captured, you can use tools like HeapHero, Eclipse MAT to analyze heap dumps.
(2). -XX:OnOutOfMemoryError
You can configure JVM to invoke any script when OutOfMemoryError is thrown. Most of the time, OutOfMemoryError doesn’t crash the application. However, it’s better to restart the application, once OutOfMemoryError happens. Because OutOfMemoryError can potentially leave application in an unstable state. Requests served from an unstable application instance can lead to an erroneous result.
Example:
-XX:OnOutOfMemoryError=/scripts/restart-myapp.sh
When you pass this argument, JVM will invoke “/scripts/restart-myapp.sh” script whenever OutOfMemoryError is thrown. In this script, you can write code to restart your application gracefully.
(3). -XX:+CrashOnOutOfMemoryError
When you pass this argument JVM will exit right when it OutOfMemoryError is thrown. Besides exiting, JVM produces text and binary crash files (if core files are enabled). But personally, I wouldn’t prefer configuring this argument, because we should always aim to achieve a graceful exit. Abrupt exit can/will jeopardize transactions that are in motion.
I ran an application which generates OutOfMemoryError with this ‘-XX:+CrashOnOutOfMemoryError’ argument. I could see JVM exiting immediately when OutOfMemoryError was thrown. Below was the message in the standard output stream:
Aborting due to java.lang.OutOfMemoryError: GC overhead limit exceeded # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (debug.cpp:308), pid=26064, tid=0x0000000000004f4c # fatal error: OutOfMemory encountered: GC overhead limit exceeded # # JRE version: Java(TM) SE Runtime Environment (8.0_181-b13) (build 1.8.0_181-b13) # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.181-b13 mixed mode windows-amd64 compressed oops) # Failed to write core dump. Minidumps are not enabled by default on client versions of Windows # # An error report file with more information is saved as: # C:workspacetier1app-svntrunkbuggyapphs_err_pid26064.log # # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp #
From the message, you could see hs_err_pid file to be generated in ‘C:workspacetier1app-svntrunkbuggyapphs_err_pid26064.log’. hs_err_pid file contains information about the crash. You can use tools like fastThread to analyze hs_err_pid file. But most of the time information present in hs_err_pid is very basic. It’s not sufficient enough to troubleshoot OutOfMemoryError.
(4). -XX:+ExitOnOutOfMemoryError
When you pass this argument, JVM will exit right when OutOfMemoryError is thrown. You may pass this argument if you would like to terminate the application. But personally, I wouldn’t prefer configuring this argument, because we should always aim to achieve a graceful exit. Abrupt exit can/will jeopardize transactions that are in motion.
I ran the same memory leak program with this ‘-XX:+ExitOnOutOfMemoryError’ JVM argument. Unlike ‘-XX:+CrashOnOutOfMemoryError’, this JVM argument did not generate any text/binary file. JVM just exited.
*Important*: Join the AndroidVille SLACK workspace for mobile developers where people share their learnings about everything latest in Tech, especially in Android Development, RxJava, Kotlin, Flutter, and mobile development in general.
Click on this link to join the workspace. It’s absolutely free!
Like what you read? Don’t forget to share this post on Facebook, Whatsapp, and LinkedIn.
You can follow me on LinkedIn, Quora, Twitter, and Instagram where I answer questions related to Mobile Development, especially Android and Flutter.
If you want to stay updated with all the latest articles, subscribe to the weekly newsletter by entering your email address in the form on the top right section of this page.