JVM performance tuning – part 1

Many integration solution are based on the Java Virtual Machine.  Having a good understanding of the underlying machinery is essential for a well functioning integration platform.  Tuning of the Java Virtual Machine is an essntial part of that.  In a series of blog posting, we are going to focus on the tuning of the JMV.  Let’s get started with part 1.

The importance of tuning the Java Virtual Machine (JVM) is based on a few characteristics of the virtal machine:

  • The virual machine layer makes abstraction of the underlying operation system and thus increases the overhead
  • This overhead can cause Java applications to run slower than equivalent programs written in a low level language
  • Java’s advantages like memory management, exception handling, multithreading, … add costs

In order to understand the ways in which the JVM can be tuned, several aspects needs to be cleared  out first.

Java process memory

The JVM runs as a process called java on an operating system. It runs as a single process, meaning it doesn’t share memory with other processes. The size of this process is determined by 2 major blocks:

  • The java heap space (often the largest part)
  • Other memory
    • The permanent generation: contains metadata: data about classes and methods, statics, … If too many classes are loaded a “java.lang.OutOfMemoryError: Permgen space” error may occur. The size of the permgen can be configured using the -XX:PermSize=value (initial value) and -XX:MaxPermSize=value (max value)
    • Code generation: the translation of byte code into native cod
    • Socket buffers: for TCP connections. Each connection has a send and a receive buffer
    • Thread stacks: every thread has a stack. The size of the stack can be configured using the -Xss option. The default size of a thread stack is determined by the combination JVM/OS (320k for java 1.6 on windows 32-bit and 1M for java 1.6 on windows 64-bit). The larger the number of threads, the larger the total thread stack size will be. Two possible memory errors associated with the thread stack size are “java.lang.OutOfMemoryError: unable to create new native thread”. This means the JVM wants to associate a stack with a new thread, but the java process size on operating system level can’t be expanded. A “java.lang.StackoverflowError” occurs when the thread stack size is too small or when recursive code is called too often.
    • Direct memory space: the JVM allows to address memory directly outside the java heap.
    • JNI code and JNI allocated memory: for JNI programs
    • Garbage collection: introduces additional overhead

The java heap space is divided in two generations. Each generation contains objects of a different age. The java heap space generations are:

  • The young generation: new objects are created in the young generation. The object clean upof the young generation is called a minor garbage collection (minor GC). The younggeneration has two spaces:
    • Eden space: new object are created in this space. New objects that are too large to fit in here are created in the tenured space of the old generation.
    • Survivor space: divided in a “to” and a “from” survivor space. Contains objects that survived at least one minor collection. It gives objects an additional chance to “die”before being moved to the tenured space. One survivor space contains such objects,while the other is empty.
  • Old generation: has one space: the tenured space. Contains objects that survived severalminor collections. Object clean up of the old generation is called a full or major garbage collection (full GC).

The permanent generation resides outside the java heap space and contains metadata, statics and
objects responsible for a good working of the jvm garbage collector.

Author: Dimitri



Curious to know more about this topic?

Working at i8c

i8c is a system integrator that strives for an informal atmosphere between its employees, who have an average age of approx 30 years old. We invest a lot of effort in the professional development of each individual, through a direct connection between the consultants and the management (no multiple layers of middle management). We are based in Kontich, near Antwerp, but our customers are mainly located in the triangle Ghent-Antwerp-Brussels and belong to the top 500 companies in Belgium (Securex, Electrabel, UCB, etc…).

Quality Assurance

i8c is committed to delivering quality services and providing customer satisfaction. That’s why we invested in the introduction of a Quality Management System, which resulted in our ISO9001:2000 certification. This guarantees that we will meet your expectations, as a reliable, efficient and mature partner for your SOA & integration projects.

i8c - ISO9001-2015

Also worth reading

AWS AppFlow: Streamlining SaaS Integrations with AWS Services

In today’s digital world, organizations are constantly looking for ways to streamline their workflows and improve their data management processes. One of the key challenges that organizations face is integrating their various software as a service (SaaS) applications with their data management systems. This is

Read More »

Apigee Scope Validation using OpenAPI Specification

In API security and management, we often use a lot of different security mechanisms to protect the requested resource behind the API Gateway. One of these mechanisms is the validation of scopes to authorize a client on a specific sub-resource of the API. Most of

Read More »