Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Safepoints

DZone's Guide to

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

Transform incident management with machine learning and analytics to help you maintain optimal performance and availability while keeping pace with the growing demands of digital business with this eBook, brought to you in partnership with BMC.

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.

According to Peter Lawrey, 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

-XX:+PrintSafepointStatistics

–XX:PrintSafepointStatisticsCount=1 

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.

Evolve your approach to Application Performance Monitoring by adopting five best practices that are outlined and explored in this e-book, brought to you in partnership with BMC.

Topics:
jvm ,gc ,performance ,low latency ,java performance

Published at DZone with permission of Grzegorz Mirek. See the original article here.

Opinions expressed by DZone contributors are their own.

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

{{ parent.tldr }}

{{ parent.urlSource.name }}