Key JVM Performance Tuning Parameters (2016 Winter Edition)

The author presents a collection of important JVM performance‑tuning parameters (2016 winter edition), explaining their purpose and recommended values for production Java services.

-XX:AutoBoxCacheMax

When the Java process starts, the core rt.jar is loaded, which contains the Integer class and its internal IntegerCache . The cache stores Integer objects in the range -128 to +127, allowing Integer.valueOf to return cached instances for these values.

private static class IntegerCache {
    static final int low = -128;
    static final int high;
    static final Integer cache[];
    static {
        // high value may be configured by property
        int h = 127;
        String integerCacheHighPropValue =
            sun.misc.VM.getSavedProperty("java.lang.Integer.IntegerCache.high");
        if (integerCacheHighPropValue != null) {
            int i = parseInt(integerCacheHighPropValue);
            i = Math.max(i, 127);
            // Maximum array size is Integer.MAX_VALUE
            h = Math.min(i, Integer.MAX_VALUE - (-low) - 1);
        }
        high = h;
        cache = new Integer[(high - low) + 1];
        int j = low;
        for (int k = 0; k < cache.length; k++)
            cache[k] = new Integer(j++);
    }
    private IntegerCache() {}
}

The valueOf method returns a cached instance when the argument lies within the configured range; otherwise it creates a new Integer object.

public static Integer valueOf(int i) {
    assert IntegerCache.high >= 127;
    if (i >= IntegerCache.low && i <= IntegerCache.high)
        return IntegerCache.cache[i + (-IntegerCache.low)];
    return new Integer(i);
}

Therefore, the cache size can be increased, for example:

-XX:AutoBoxCacheMax=20000

-XX:+AlwaysPreTouch

By default, the operating system allocates physical memory lazily, i.e., only when the JVM first accesses a page. This can cause longer pauses during young‑generation promotion and may lead to memory fragmentation.

Adding the following flag forces the JVM to touch every page of the allocated heap at startup, ensuring the OS commits the memory up front:

-XX:+AlwaysPreTouch

GC Parameters

The article assumes Java 1.7 with the CMS (Concurrent Mark‑Sweep) collector and introduces several CMS‑related flags.

CMSInitiatingOccupancyFraction

CMS starts a collection when the old generation reaches a certain occupancy. Setting the value to 75 (instead of the default 92) triggers earlier collection.

CMSInitiatingOccupancyFraction=75

This flag must be used together with the following two options:

-XX:+UseConcMarkSweepGC
-XX:+UseCMSInitiatingOccupancyOnly

MaxTenuringThreshold

By default, after 15 young GCs an object that survives in the Survivor space is promoted to the old generation. Reducing the threshold to 6 limits the time objects stay in Survivor, improving copy‑algorithm efficiency.

-XX:MaxTenuringThreshold=6

ExplicitGCInvokesConcurrent

When off‑heap memory (e.g., Netty's DirectByteBuffer ) is used, calling System.gc() triggers a full GC, pausing the application. With CMS, adding the flag below makes System.gc() invoke a concurrent CMS collection instead.

-XX:+ExplicitGCInvokesConcurrent

Note: when this flag is enabled, do not also set -XX:+DisableExplicitGC , which would block System.gc() entirely.

Memory Parameters

-Xmx, -Xms

Typical settings allocate 4 GB for both maximum and initial heap size.

NewRatio

Since most GC work occurs in the young generation, increasing its proportion can reduce young‑GC pauses. A ratio of 1 (i.e., a 50/50 split between young and old generations) is recommended.

-XX:NewRatio=1

(End of article)