Java.lang.VirtualMachineError is thrown when Java virtual machine encounters an internal error or resource limitation which prevents it from functioning. It’s a self-defensive mechanism employed by JVM to prevent the entire application from crashing. In this article lets discuss different types of VirtualMachineError, their characteristics, reasons why they get triggered and potentials solutions to fix them. Guest post by Ram Lakshmanan.
Every single day, millions & millions of people in North America—bank, travel, and commerce—use the applications that Ram Lakshmanan has architected. Ram is an acclaimed speaker in major conferences on scalability, availability, and performance topics. Recently, he has founded a startup, which specializes in troubleshooting performance problems.
Originally published here.
Types of VirtualMachineError
There are four different types of VirtualMachineError:
Let’s review these types in detail in this section
# a. OutOfMemoryError
Just like OMG (Oh My God) acronym, OOM (OutOfMemoryError) is quite popular among DevOps community :-). Most DevOps engineers think that there is one OutOfMemoryError. But there are 8 different flavors of OutOfMemoryError:
- java.lang.OutOfMemoryError: Java heap space
- java.lang.OutOfMemoryError: GC Overhead limit exceeded
- java.lang.OutOfMemoryError: Requested array size exceeds VM limit
- java.lang.OutOfMemoryError: Permgen space
- java.lang.OutOfMemoryError: Metaspace
- java.lang.OutOfMemoryError: Unable to create new native thread
- java.lang.OutOfMemoryError: Kill process or sacrifice child
- java.lang.OutOfMemoryError: reason stack_trace_with_native_method
Each flavor is triggered for different reasons. Similarly, solutions are also different for each flavor of OutOfMemoryError. Here is a beautiful one-page document that summarizes all different flavors of OutOfMemoryError, their causes and solutions.
In general, OutOfMemoryError can be diagnosed and fixed by analyzing Garbage Collection logs and Heap Dumps. Since analyzing Garbage Collection logs manually can be tedious, you may consider using free tools like: GCeasy, HP Jmeter, IBM GC analyzer. Similarly to analyze heap dumps, you may consider using free tools like: HeapHero, Eclipse MAT.
# b. StackOverflowError
Thread’s stack is storing information about the methods it’s executing, primitive datatype values, local variables, object pointers, and return values. All of them consume memory. If thread’s stack sizes grow beyond the allocated memory limit, then java.lang.StackOverflowError is thrown. This problem typically happens when a thread recursively invokes same function again and again as a result of a bug in the executing program. More details on how to debug StackOverflowError and all possible solutions to fix it can be found in this article.
# c. InternalError
java.lang.InternalError is thrown by JVM when there is a:
- Fault in the software implementing the virtual machine,
- Fault in the underlying host system software
- Fault in the hardware.
But rarely you will encounter InternalError. To understand what specific scenarios may cause InternalError, you may search for ‘InternalError’ string in Oracle’s Java Bug database. At the time of writing this article (Dec’ 20, 2018), there are only 200 defects reported for this error in Oracle java bug database. Most of them are fixed.
# d. UnknownError
java.lang.UnknownError is thrown when an exception or error has occurred, but the Java virtual machine is unable to report the actual exception or error. Seldom you will see UnknownError. In fact, when searching for ‘UnknownError’ in Oracle Java Bug database at the time of writing this article (Dec’ 20, 2018), there are only 2 defects found reported.
VirtualMachineError has a couple of primary characteristics:
- Unchecked Exception
- Synchronous & asynchronous delivery
Let’s discuss these two characteristics in this section.
(1). Unchecked Exception
There are two types of Exceptions:
- Checked exceptions
- Unchecked exceptions
Exceptions which are checked at compile time called Checked Exception. If some methods in your code throw a checked exception, then the method must either handle the exception or it must specify the exception using throws keyword. Examples of the checked exceptions are: IOException, SQLException, DataAccessException, ClassNotFoundException …
Unchecked exceptions do not have this requirement. They don’t have to be caught or declared thrown. All types of VirtualMachineError are unchecked exceptions.
(2). Synchronous & asynchronous Delivery
Exceptions can be thrown in two modes:
Synchronous exceptions happen at a specific program statement, no matter, how many numbers of times program is executed in a similar environment. Example of synchronous exceptions are NullPointerException, ArrayIndexOutOfBoundException, etc.…
Asynchronous exceptions can happen at any point in time and it can happen in any part of program statement. There will be no consistency where it can be thrown. All the VirtualMachineError are thrown asynchronously, but sometimes they can also be thrown synchronously. StackOverflowError may be thrown synchronously by method invocation as well as asynchronously due to native method execution or Java Virtual Machine resource limitations. Similarly, OutOfMemoryError may be thrown synchronously during object creation, array creation, class initialization, and boxing conversion, as well as asynchronously.