General terminology

  • JDK - Java Development Kit is a development toolkit for developing java applets and apps. It includes : JRE(loader/interpreter), compiler(javac), document generator(javadoc), archiver(jar) and other tools required for development. JDK = JVM + JRE
  • JRE - Java Runtime Environment is provides the runtime environment for the java applets and apps. It contains core classes and supporting files to load/interpret bytecode. It also contains the JVM. JRE = JVM + lib classes
  • JVM - Java Virtual Machine provide runtime environment for executing the java bytecode. It is an abstract machine hence platform dependent according to kernel of the OS. While Java language itself is platform independent.

Java Hotspot: JVM space structure

When java application starts up, certain memory space are allocated to it. These space are broadly classify into Heap Space, Method area/Permanent Generation and Native area. Code Cache (Virtual or reserved) is Used for compilation and storage of native code.

Heap space

  • Java Objects are created in heap.
  • Heap are divided into 2 parts for Garbage Collection: Young/New Generation and Old/Tenure Generation.
  • Young/New Generation are further divided into 3 parts : Eden space, Survivor 0 and Survivor 1 space.
  • When java objects are created its first created in Eden space and after minor subsequent minor garbage collection if an object survives it moves to S0 and then S1 before major garbage collection moves it to old/tenure generation.
  • Old Generation - Object that has exist sometime in the survivor space.
  • A Java Virtual Machine implementation may provide the programmer or the user control over the initial size of the heap, as well as, if the heap can be dynamically expanded or contracted, control over the maximum and minimum heap size.
  • If a computation requires more heap than can be made available by the automatic storage management system, the Java Virtual Machine throws an java.lang.OutOfMemoryError: Heap space.

Method area

  • Also known as the Permanent Generation where it contains the permanent class metadata and descriptors information so PermGen space always reserved for classes and those that is tied to the classes for example static members.
  • A Java Virtual Machine implementation may provide the programmer or the user control over the initial size of the method area, as well as, in the case of a varying-size method area, control over the maximum and minimum method area size.
  • If memory in the method area cannot be made available to satisfy an allocation request, the Java Virtual Machine throws an java.lang.OutOfMemoryError: PermGen space.

Java8 Update: PermGen is replaced with Metaspace which is very similar. Main difference is that Metaspace re-sizes dynamically i.e., It can expand at runtime. Java Metaspace space: unbounded (default)

Native Area

  • Store local variable and function call.
  • Each thread in a Java application has its own stack. The stack is used to hold return addresses, function/method call arguments, etc. So if a thread tends to process large structures via recursive algorithms, it may need a large stack for all those return addresses and such.
  • If the computation in a thread requires a larger native method stack than is permitted, the Java Virtual Machine throws a java.lang.StackOverFlowError.
  • Variables stored in stacks are only visible to the owner Thread while objects created in the heap are visible to all thread. In other words, stack memory is kind of private memory of Java Threads while heap memory is shared among all threads.
  • If native method stacks can be dynamically expanded and native method stack expansion is attempted but insufficient memory can be made available, or if insufficient memory can be made available to create the initial native method stack for a new thread, the Java Virtual Machine throws an java.lang.OutOfMemoryError.

Java Opts

  • Standard Options: Options that begin with - are Standard options are expected to be accepted by all JVM implementations and are stable between releases Standard options recognized by the Java HotSpot VM are described on the Java Application Launcher reference pages for Solaris & Linux.
  • Non-Standard Options: Options that begin with -X are non-standard (not guaranteed to be supported on all VM implementations), and are subject to change without notice in subsequent releases of the JDK.

  • Developer Options: Options that are specified with -XX are not stable and are subject to change without notice.

  • Boolean JVM options can be  turned on with -XX:+ and can be turned off with -XX:-.
  • Numeric JVM Options can be set with -XX:=. Numbers can include ‘m’ or ‘M’ for megabytes, ‘k’ or ‘K’ for kilobytes and ‘g’ or ‘G’ for gigabytes (for example, 32k is the same as 32768).
  • String JVM options can be set by using -XX:=, and usually used to specify a file, a path, or a list of commands.

Below are some common opts:

Heap space

Switch Description
-Xms Initial heap size for when the JVM starts.
-Xmx Sets the maximum heap size.
-Xmn Sets the size of the Young Generation.

Perm Generation

Switch Description
-XX:PermSize Sets the starting size of the Permanent Generation.
-XX:MaxPermSize Sets the maximum size of the Permanent Generation

Native Area

Switch Description
-Xss Tread Stack size

Garbage Collection (GC)

Types of GC

  • Serial GC
  • Parallel GC
  • G1GC

Serial GC

The serial collector is the default for client style machines in Java SE 5 and 6. With the serial collector, both minor and major garbage collections are done serially (using a single virtual CPU). In addition, it uses a mark-compact collection method. This method moves older memory to the beginning of the heap so that new memory allocations are made into a single continuous chunk of memory at the end of the heap. This compacting of memory makes it faster to allocate new chunks of memory to the heap.

Usage Cases
The Serial GC is the garbage collector of choice for most applications that do not have low pause time requirements and run on client-style machines. It takes advantage of only a single virtual processor for garbage collection work (therefore, its name). Still, on today’s hardware, the Serial GC can efficiently manage a lot of non-trivial applications with a few hundred MBs of Java heap, with relatively short worst-case pauses (around a couple of seconds for full garbage collections).

Another popular use for the Serial GC is in environments where a high number of JVMs are run on the same machine (in some cases, more JVMs than available processors!). In such environments when a JVM does a garbage collection it is better to use only one processor to minimize the interference on the remaining JVMs, even if the garbage collection might last longer. And the Serial GC fits this trade-off nicely.

Finally, with the proliferation of embedded hardware with minimal memory and few cores, the Serial GC could make a comeback.

Parallel GC

The parallel garbage collector uses multiple threads to perform the young generation garbage collection. By default on a host with N CPUs, the parallel garbage collector uses N garbage collector threads in the collection. The number of garbage collector threads can be controlled with command-line options: -XX:ParallelGCThreads=<desired number>.

On a host with a single CPU the default garbage collector is used even if the parallel garbage collector has been requested.
On a host with two CPUs the parallel garbage collector generally performs as well as the default garbage collector and a reduction in the young generation garbage collector pause times can be expected on hosts with more than two CPUs.

Usage Cases
The Parallel collector is also called a throughput collector. Since it can use multiple CPUs to speed up application throughput. This collector should be used when a lot of work need to be done and long pauses are acceptable. For example, batch processing like printing reports or bills or performing a large number of database queries.

The Concurrent Mark Sweep (CMS) Collector

The Concurrent Mark Sweep (CMS) collector (also referred to as the concurrent low pause collector) collects the tenured generation. It attempts to minimize the pauses due to garbage collection by doing most of the garbage collection work concurrently with the application threads. Normally the concurrent low pause collector does not copy or compact the live objects. A garbage collection is done without moving the live objects. If fragmentation becomes a problem, allocate a larger heap.

Note: CMS collector on young generation uses the same algorithm as that of the parallel collector.

Usage Cases
The CMS collector should be used for applications that require low pause times and can share resources with the garbage collector. Examples include desktop UI application that respond to events, a webserver responding to a request or a database responding to queries.

The G1 Garbage Collector

The Garbage First or G1 garbage collector is available in Java 7 and is designed to be the long term replacement for the CMS collector. The G1 collector is a parallel, concurrent, and incrementally compacting low-pause garbage collector that has quite a different layout from the other garbage collectors described previously.

GC overall switches

Switch Description
-XX:+UseSerialGC Both minor and major garbage collections are done serially.
-XX:+UseParallelGC Multi-thread young generation collector with a single-threaded old generation collector.
The option also does single-threaded compaction of old generation.
-XX:+UseParallelOldGC The GC is both a multithreaded young generation collector and multithreaded old generation
collector.
-XX:+UseConcMarkSweepGC Enable the CMS Collector.
To set the number of threads use -XX:ParallelCMSThreads=<n>.
-XX:+UseG1GC Enable the G1 Collector.
The G1 collector is a parallel, concurrent, and incrementally compacting low-pause garbage collector.

Reference: