Build1 publisher2 min readPublished
G1 replaces Serial GC as JDK 27's default on resource-constrained systems
JDK 27 drops the automatic fallback to Serial GC on limited hardware. A JVM in a tight container now gets G1 unless an operator asks for something else, and compact object headers move footprint in the same release.
The Engineer · Build desk
What happened
- JDK 27 makes G1 the default garbage collector in all cases, so an alternative collector now has to be requested explicitly on the command line.
- Until this release the JVM used Serial GC when only limited system resources were available, even though G1 had been the de facto default since JDK 9.
- Flight Recorder now redacts passwords and API keys passed as JVM arguments or environment variables by default, using a published list of glob filters.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- decision Anyone shipping a JVM in a resource-tight container now names the collector in the image or accepts G1 in a place the runtime used to choose Serial for them.
- constraint A footprint or pause-time comparison against the previous JDK varies two defaults at once, so one before-and-after number cannot attribute the change to either.
- cost Verification lands on the deployer, and the release notes' own advice is to test and measure each GC choice and configuration.
Serial GC used to be selected for you when only limited system resources were available, and nobody typed a flag to get it [2]. JDK 27 stops making that call: G1 is the default in all cases unless you explicitly request an alternative collector [1]. The runtime release notes published on inside.java do not define limited system resources or show the measurements behind their judgement that G1 is "still often the best option" there [8].
In a tight container the question is which resource you are shortest of. The note answers with tradeoffs: each collector "makes a set of tradeoffs between CPU utilization, memory utilization, pause time" [7]. Which axis binds on your service is a separate question. For it to resolve in G1's favour on your workload, the KPI you care about has to be one the note's own hedge leaves standing. The note warns that "specific implementation details within a GC might positively or negatively impact the KPIs of your application" [13].
The before-and-after comparison is two changes deep. Compact object headers, final in JDK 25, are also enabled by default in 27, and the note puts their effect at roughly a 20% reduction in overall heap size [4][5]. Take that at face value and the same heap ceiling holds about 1.25 times the live objects it held before, since 1 divided by 0.8 is 1.25 [12]. A lower resident set on 27 therefore folds both changes together. Run the constrained case once with -XX:-UseCompactObjectHeaders to get the header change out of the number [5].
Defaults moved elsewhere in this release too. Flight Recorder now redacts passwords and API keys supplied as JVM arguments or environment variables without being asked, using a glob filter list that ships with entries such as *password*, *token* and *private*key*, and redact-key=none turns the defaults off [6][9]. Three of the nine JEPs in JDK 27 are primarily runtime changes [11].
In my view the right move for a small-footprint image is to state the collector in the image rather than inherit it, because an explicit request is the only thing that keeps 27 off G1 [1]. The header change has a one-flag rollback in -XX:-UseCompactObjectHeaders [5].
What to watch
- Whether HotSpot documentation ever spells out the resource threshold that used to select Serial GC, now that the selection is gone.
- Reports of pause-time or resident-set regressions from small-container JVM deployments after the JDK 27 upgrade.
- Whether a later release removes the -XX:-UseCompactObjectHeaders escape hatch, leaving the footprint change unrollable.