Laxmikant
Laxmikant

Reputation: 1611

How to achieve deterministic GC pause in Java 7+?

As after Jrockit is no more available, hence is there any way to achieve deterministic (no more that x ms) GC pause? I am trying with G1 GC in java_8_65 but it is non-deterministic and many times i see young gc pauses greater than -XX:MaxGCPauseMillis which is expected but not as per my requirement.

Upvotes: 1

Views: 431

Answers (4)

naXa stands with Ukraine
naXa stands with Ukraine

Reputation: 37916

The release of Java 11 contains a brand new Garbage Collector, ZGC, that promises very low pause times.

The goal of this project is to create a scalable low latency garbage collector capable of handling heaps ranging from a few gigabytes to multi terabytes in size, with GC pause times not exceeding 10ms.

Upvotes: 1

Speakjava
Speakjava

Reputation: 3392

The simple answer is no. All GC used by Hotspot and other JVMs (like Zing from Azul, who I work for) are inherently non-deterministic. You can certainly tune a GC to achieve your latency goal for most of the time and using Zing would give you much more reliable results because it performs a compacting collection truly concurrently with the application threads (so, therefore, does not have stop-the-world pauses).

The problem is that, if your application suddenly hits a point where it starts allocating objects at a much higher rate or generates garbage much faster than you have tuned for, you will start seeing pauses that exceed your goal. This is simply the way GC works.

The only way to get true deterministic behaviour like you're looking for would be to use a real-time JVM (look up the RTSJ spec) that would also require a real-time operating system underneath. The drawback to doing this is often your throughput will suffer.

Upvotes: 3

Gamlor
Gamlor

Reputation: 13248

One other options could be OpenJ9 Metronome GC. As far as I know, it is design for deterministic, short pauses for real time apps. According to the documentation the default is 10 millisecond pauses. However, it will of course need more CPU and is more design for small heaps.

I never used it, so I cannot share any experience.

Upvotes: 1

the8472
the8472

Reputation: 43052

Your options are

  • do some tuning until G1 performs as expected
  • switch to another collector available in the JVM you're using, e.g. CMS
  • switch to a different JVM which offers collectors with stronger guarantees
  • optimize your application to reduce GC pressure or worst case behavior
  • throw more hardware at the problem (more or faster CPU cores, more RAM)

Upvotes: 1

Related Questions