Starting with Java 9, the JVM quietly adopted a new internal representation for the java.lang.String class. The feature is called Compact Strings and, unless you went looking, you probably never noticed the change—yet it can shrink your application’s heap by 10-30% and speed up operations on text-heavy workloads.

This post explains what compact strings are, how this subtle change delivers massive performance wins, and how you can measure the benefit on your own code. Get ready to reclaim your RAM!

The Memory Drain Java 9 Tried to Solve

Prior to JDK 9, every character inside a String was stored as a 16-bit char, using the UTF-16 encoding.

The problem? For common languages like English, or text data formats like XML, JSON, log messages, and HTTP headers, most characters fall within the Latin-1 (ISO-8859-1) set, which perfectly fits into a single 8-bit byte.

This meant that for a vast majority of applications, half of every character array was filled with redundant zeroes. That silent waste translated directly to:

• Larger Heap Footprint: Your application demands more RAM.
• More GC Pressure: The Garbage Collector has to work harder and longer.
• Lower CPU-Cache Locality: Data is scattered, slowing down processing.

While developers could manually pack bytes, it came at the cost of code clarity and API compatibility. Clearly, a JVM-level fix was needed to make string handling efficient by default.

What Exactly Is a “Compact String”?

The solution, introduced in JEP 254, was brilliant in its simplicity.

Since JDK 9, each String instance no longer stores a char[] internally. Instead, it stores a byte[] along with an extra private field called coder. This coder field remembers the encoding:

The Logic

The JVM is smart:

1. When a string is created, it checks if every single character fits within the Latin-1 range (0-255).
2. If it does, the VM uses the 1-byte per character Latin-1 form (coder = 0).
3. Otherwise, it falls back to the legacy 2-byte per character UTF-16 form (coder = 1).

Crucially, this change is completely transparent to your code. Public APIs like new String(), charAt, length, and regular expressions remain unchanged. Only the internal memory layout differs.

How Much Memory Do You Really Save?

The savings aren’t theoretical—they’re dramatic for text-heavy workloads.

Let’s look at a concrete measurement. The following JMH micro-benchmark creates one million randomly generated “English” strings (Latin-1 compatible) of an average length of 43 characters and compares heap usage.

package com.example.benchmarks;

import org.openjdk.jmh.annotations.*;
import org.openjdk.jmh.infra.Blackhole;
import org.openjdk.jmh.runner.Runner;
import org.openjdk.jmh.runner.RunnerException;
import org.openjdk.jmh.runner.options.Options;
import org.openjdk.jmh.runner.options.OptionsBuilder;
import org.apache.lucene.util.RamUsageEstimator; // Dependency needed for sizeOf

import java.util.Random;
import java.util.concurrent.TimeUnit;

@State(Scope.Benchmark)
@Warmup(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
@Measurement(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
@Fork(value = 1) // Run one JVM fork
@BenchmarkMode(Mode.SingleShotTime) // Measures the total time for a single run
@OutputTimeUnit(TimeUnit.MILLISECONDS)
public class CompactStringMemoryBenchmark {

    @Param({"1000000"})
    public int count; // Defined as public field for JMH parameter injection

    private String[] data;

    /**
     * Setup method to initialize the data array *before* the benchmark runs.
     * This creates 1,000,000 Latin-1 compatible strings.
     */
    @Setup(Level.Trial)
    public void setup() {
        data = new String[count];
        Random r = new Random(1);
        
        // Populate the array with Latin-1 (ASCII) compatible strings
        for (int i = 0; i < count; i++) {
            int len = 30 + r.nextInt(26);          // 30-55 chars
            StringBuilder sb = new StringBuilder(len);
            for (int j = 0; j < len; j++) {
                // 'a' (97) + 0-25 -> guaranteed Latin-1
                sb.append((char) ('a' + r.nextInt(26)));
            }
            data[i] = sb.toString();
        }
    }

    /**
     * The benchmark method. 
     * It calculates the retained heap size of the entire data array.
     */
    @Benchmark
    public long retained() {
        // RamUsageEstimator.sizeOf returns the shallow size of 'data' + the deep size of all referenced String objects
        return RamUsageEstimator.sizeOf(data); 
    }

    // Optional: Main method to run the benchmark programmatically
    public static void main(String[] args) throws RunnerException {
        Options opt = new OptionsBuilder()
                .include(CompactStringMemoryBenchmark.class.getSimpleName())
                // .param("count", "1000000") // Optionally set parameters here
                .build();

        new Runner(opt).run();
    }
}

The results on a 64-bit HotSpot JVM with compressed Oops are compelling:

Real-world services that cache or log a lot of text often see 10-30% reductions in live-set size, which directly translates into shorter GC pauses and higher throughput.

Performance Impact on Common Operations

The benefit isn’t just memory; many common String operations are now significantly faster because they can operate directly on a compact byte[].

• String::hashCode: The hash is computed directly on the byte[] for Latin-1 strings, improving cache locality and cutting CPU by ~15% for ASCII keys.
• String::equals / String::compareTo: Two LATIN1 strings can be compared with a simple memcmp. The JIT compiler emits vectorized instructions (SIMD) for this, giving up to 2× speed-ups.
• substring, split, most regex paths: These operations now copy and process fewer bytes, making them faster and friendlier to the Garbage Collector’s write barrier.

Edge Case: If your code routinely mixes scripts (emoji, CJK, math symbols), the VM keeps everything in UTF-16, and you simply fall back to pre-Java 9 performance. No harm done!

Gotchas and Tips for the Compact Era

While Compact Strings are mostly transparent, a few considerations can help you maximize the benefit and avoid common pitfalls:

Update Your Profiling ToolsLibraries that measure object size, such as JOL (Java Object Layout), Jamm, or profilers like YourKit, had to be updated to support the new byte[] layout. Ensure you are using modern versions, or they may report incorrect sizes.

Avoid the new String(bytes, charset) Anti-Pattern If you already have a byte array in UTF-8, use:

// Good: VM can often decode directly into a compact String
String s = new String(bytes, StandardCharsets.UTF_8);

Avoid reading the bytes into a temporary char[] first. Let the VM handle the decoding directly so it can choose the narrowest, most compact encoding.

StringBuilder is Compact-AwareStringBuilder also became byte-based internally. When the builder is converted to a String via toString(), the VM chooses the narrowest encoding. Appending only ASCII characters and then calling toString() ensures the final string is compact!

Switching the Feature Off (Diagnostic Only)Although the VM defaults to compact strings, you can disable it for benchmarking or compatibility:

java -XX:-CompactStrings MyApp

Disabling forces every String to UTF-16. This flag is diagnostic and may disappear in future releases—use only for testing.

Quick FAQ

• Does Compact Strings change String’s public API? No. length() still returns the number of 16-bit code units (chars), charAt returns the UTF-16 code unit, etc. Your source code is 100% compatible.
• Can I force a string to stay Latin-1? No. If any character needs a > 1 byte representation (e.g., a Chinese character or a less common European symbol), the VM must upgrade the whole string to UTF-16 to maintain data integrity.
• Does G1 / Parallel / Shenandoah benefit equally? All collectors benefit from smaller objects (less to manage). G1 and Shenandoah especially enjoy reduced region evacuation times because regions hold more useful data and are faster to copy.

The Bottom Line

Java 9 replaced String’s internal char array with a byte array plus a coder flag. ASCII/Latin-1 heavy strings occupy half the RAM, improve throughput, and shorten GC pauses, while full-Unicode strings stay unchanged.

No source-code changes are required, but keep an eye on profilers and memory meters to confirm the win in your own application.

Enable (it’s the default), measure, and enjoy the free performance upgrade—happy coding!