Over a million developers have joined DZone.

When Application Threads Can Be Stopped: Safepoints

DZone's Guide to

When Application Threads Can Be Stopped: Safepoints

We talk about safepoints, stop-the-world pauses, and a few other ways threads can impact the performance of your JVM-based application.

· Performance Zone ·
Free Resource

Built by operators for operators, the Sensu monitoring event pipeline empowers businesses to automate their monitoring workflows and gain deep visibility into their multi-cloud environments. Get started for free today.

There are two logical groups of threads in Java applications:

  • Application threads performing application logic.
  • Threads performing GC.

When performing operations such as heap compaction, GC threads move some objects around and those objects cannot be used by any of the application threads, because their physical location may change. This leads to so called stop-the-world pause.

A stop-the-world (STW) pause is when all application threads are stopped. These pauses have one of the biggest impacts on Java application performance. The basic concept behind GC tuning is to minimize those pauses. Even though there are some differences between GC algorithms, all of them have stop-the-world pauses during the collection of the young generation (minor GC).

However, application threads cannot be stopped at any time. This is where safepoints come into play. The following definition of safepoint comes from the HotSpot glossary:

A point during program execution at which all GC roots are known and all heap object contents are consistent. From a global point of view, all threads must block at a safepoint before the GC can run.

What it basically means is that a safepoint is the point in the execution when the JVM is in a state which can be safely viewed and manipulated by other threads (especially by GC threads). 

Stop-the-world pauses performed by GC are not the only situations where safepoints are used. They can be also used during code deoptimization, hot swaps, or when the code cache is flushed.

Seems that there is no special rule where the JVM will place safepoints. It can vary from Java version to version, but some sources available on the internet claim that it happens usually after return from calls or after a back jump from a loop for JIT-compiled code.

There are a couple of flags which can be pretty handy when tracing safepoints:

-XX:+PrintGCApplicationStoppedTime - prints pause time for all safepoints (not only GC ones).

The output will look like this:

Application time: 0.2410613 seconds
Total time for which application threads were stopped: 0.0511005 seconds



The flags above print out the name of the operation that triggered the pause and some additional information (such as the number of threads stopped and a timestamp when the event occurred).

All these flags print the information to the standard output, not to the GC log.

Download our guide to mitigating alert fatigue, with real-world tips on automating remediation and triage from an IT veteran.

jvm ,gc ,performance ,low latency ,java performance

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}