JVM Performance Tuning Part 2: Garbage Collection Theory

Garbage collection is often the most misunderstood feature of the Java Virtual Machine. It’s often advertised as moving the responsibility of memory management from the application developer to the Java Virtual Machine. This just isn’t the case. On the other hand, the developer doesn’t need to put too much effort in pleasing the garbage collector.
A good understanding of garbage collection theory is necessary for writing high performant applications for the Java platform. Part 2 of the JVM performance tuning blog entries will discuss the theoretical process of garbage collection in detail.

An important question we could ask ourselfs is why we should care about garbage collection?
There is a cost related to the allocation and collection of memory. It can play an important role in how the software performs especially when the application requires large amounts of RAM and forces the OS to use virtual memory. This behaviour often occurs when programs have memory leaks, meaning that memory will be allocated, but not properly released. Although the JVM is responsible for freeing unused memory, a developer has to make it clear what is being unused.

Garbage collection is the process of cleaning up unreachable java objects. Object are said to be unreachable when no more strong reference to it exist. As soon as an object is unreachable it can be collected by the GC. The object is a candidate for collection, but this doesn’t mean it will be immediately collected.

The global working of the garbage collection contains three phases:

  • Lock it down: Objects participating in garbage collection first need to be locked.
  • Mark: iteration phase. Al unreachable object will be marked.
  • Sweep: sweeping phase of al the marked objects.

No mather what type of garbage collector is being used, these three phases can be found in any of them. The most import characteristics of different types of garbage collectors are the different kind of strategies being used:

  • Serial versus Parallel: Serial GC uses only one thread to perform garbage collection, even when multiple CPU’s are available. Parallel GC uses multiple threads to execute GC in parallel. This introduces a little more overhead, but the use of multiple thread decreases the total GC overhead.
  • Concurrent versus Stop the World: A stop the world GC stops all the current running application threads at the moment the garbage collector will start cleaning up the dead objects. At that moment the application seems to be frozen. With a concurrent GC only a small part of the overal GC process will stop the application threads. The largest part of GC occurs concurrently with the application threads. Since the state of an object can change during concurrent GC, this type of GC introduces extra overhead an memory requirements.
  • Compacting versus non-compacting versus copying: At the moment the GC has deleted the unreachable objects, the GC can decide to perform a compacting operation. It means all the remaining objects will be put next to each other in the java heap to avoid fragmentation. Compacting introduced extra overhead during GC, but makes allocation of new objects faster, since the JVM doesn’t need to search for a place in the fragmented heap to store the object. A copying collector copies the objects to another place in memory.
  • CMS: concurrent mark sweep (explained in detail later)

GC performance can be measured based on performance metrics:

  • Throughput: % of the time not spent on GC
  • Garbage Collection Overhead: % of the time spent on GC
  • Pause Time: the time application threads will be stopped to perform GC
  • Frequency of Collection: how often GC occurs
  • Footprint: how many resources (memory and CPU) the GC needs
  • Promptness: the time between an object become garbage and the time the object will be cleaned
blogger

blogger

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 »