Child pages
  • Tuning the JVM

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


  • Metaspace is the location where he JVM stores application metadata and is unlimited by default.

  • It is important to note that if not sized appropriately then if the JVM resizes Metaspace, a full GC must be done, which is expensive.


    GSA: I don't expect this kind of memory to need a lot of tuning, maybe just remove that section ?

    WM: Ok, but if Metaspace is resized (too small) then we require a time-consuming full-GC. I think it's not that well-known so we should mention it. I'll reduce it, to reduce its importance but keep the section with that detail in it.

    GSA: Metaspace is where JVM stores classes, it's not OldGen, so the sizing should be dictated by the size of the application (all the classes that need to be loaded in memory), or am I mistaken ?

    (Will remove Tuesday 30/6/2020 if no further comment)


-serverEnsures the JVM uses server-optimised configuration, compilation and execution. This is the default with a 64-bit JVM.



Configure the initial and maximum heap space:

  • Equivalent to -Xms and -Xmx flags respectively.
  • Oracle recommend that these figures are set the same to avoid expensive allocation operations. However, recent improvements in G1GC with its adaptive optimization algorithm (see below) means that this may limit vertical scaling. Though it is still recommended to follow this practice, if using G1GC, consider testing individual initial and maximum values too.
  • As a start point, IG has been shown to operate well in performance testing with a heap size of 5Gb. That is, with this sized heap, even with more memory available, a memory increment was never done.



Configure the initial and maximum YoungGen space:

  • This configuration is important to IG as a large consumer of Eden space.
  • Incrementally test to optimise, with anticipated concurrent load in a pre-production environment. The maximum should be within the overall allocated maximum heap-size (-Xmx), leaving space for non-heap memory.
  • If using G1GC, it is advised not to set these values and instead allow G1GC to optimise based on use. As ever, this should be tested.



Prevent String duplication and so conserve memory (java 8u20+), reducing GC needs. The threshold can be provided to specify the age after which a String becomes a candidate for deduplication.


GSA: why not, but do we think that this can have a notable impact on our performances ?

WM: It's documented everywhere as advisable. It's also advised in the DJ tuning guide for 7.0. It's basically the inlining of Strings, as used to be the case pre-java8.

(Will remove Tuesday 30/6/2020 if no further comment)


Configure the number of transitions between survivor spaces before an object is moved to OldGen.

Because IG largely consumes YoungGen space, we can determine that anything that eventually would live in OldGen space could be moved there early to free up Eden space and reduce objects transitioning between survivor spaces. We could therefore set -MaxTenuringThreshold to a low value, possibly as low as 1 to accomplish this.


GSA: Good, this is exactly the kind of description that is useful to our users: it explains why this is worth considering this option

WM: Thanks

(Will remove Tuesday 30/6/2020 if no further comment)



Configure initial and maximum Metaspace size (from java 8). IG 


GSA: Unsure if we should keep this one in the doc, for sure not in the first positions, it's relatively less important than young/old gen settings

WM: Probably not vital but it is included in other guides and I think it's important to note we only need a smallish Metaspace. I've moved it to last position, as I want to describe it as II've provided a recommended default.

GSA: Smallish until we use SAML (smile)

(Will remove Tuesday 30/6/2020 if no further comment)



GSA: If we don't provide added values, I would not bother adding these things in our doc, a pointer to the official doc page would be enough (and easier to maintain)

Added value like: why this is interesting for IG, or return of experience like we observed a noticeable impact when ...

WM: When you say added value though, the below is taken from looking into multiple GC tests and guides, and is intended only as a guide for IG to consolidate info (without having done exhaustive testing). I think it's therefore still very useful. 

GSA, when I say added value, I mean we found a correlation that we can explain, otherwise it's not really more that just copy paste of the GC doc (hoping there is one somewhere)

(Will remove Tuesday 30/6/2020 if no further comment)

-XX:+UseParallelGCUse the Parallel garbage collector.
-XX:MaxGCPauseMillis=<duration in milliseconds>Supports configuration of the target max time to pause in GC. This is purely a goal and not guaranteed. It does, however, allow some configuration between throughput (longer pauses) and latency (shorter pauses). Test values between 500ms - 2000ms.
-XX:GCPauseTimeInterval=<duration in milliseconds>Supports configuration of the ideal max time between pauses in GC. This is purely a goal and not guaranteed. It does, however, allow some configuration between throughput (longer pauses) and latency (shorter pauses). Test values between 500ms - 2000ms.
-XX:GCTimeRatio=<percent value>Supports configuration of the optimal ratio between time in GC and application time. This ratio is 1% by default and should not be configured to be greater than 5%.
-XX:ParallelGCThreads=<size> Number of threads to use in parallel operations




Adaptive sizing of each generation can be controlled using parameters using these parameters. The default increment is 20%. The -XX:AdaptiveSizeDecrementScaleFactor is the percentage to decrease on decrement, as a factor of the increment size. Default is 5%.