Virtuální stroj Javy 27 volí garbage collector G1 i tam, kde dosud spouštěl Serial

Java 27 vyšla 15. září 2026. Mark Reinhold v oznámení napsal, že vydáním se stalo sestavení 35, tedy druhý kandidát z 20. srpna, protože od té doby nikdo nenahlásil chybu nejvyšší úrovně. Vydání nese devět JEPů. Tři z nich se projeví pouhým přechodem na novou verzi, protože mění výchozí chování; zbývajících šest si programátor musí zapnout nebo zavolat sám.

Serial vypadl z automatického výběru

Garbage collector je ta část virtuálního stroje, která za běhu uvolňuje objekty, na které už program nedrží odkaz. HotSpot jich má několik a každý je vyladěný jinak: ZGC na krátké odmlky, Parallel na propustnost, G1 na kompromis mezi obojím. Kdo si žádný nevybere, dostane ten, který si stroj zvolí sám.

A právě tenhle automat se mění. Od JDK 9, kde ho zavedl JEP 248, vybíral stroj na serverech G1, ale ve stísněných poměrech přepnul na Serial. Hranice byla jediný procesor nebo míň než 1 792 MB fyzické paměti. JEP 523 tenhle rozcestník ruší: bez volby na příkazové řádce dostane každý G1, bez ohledu na počet jader a velikost paměti.

Důvodem je devět let práce na G1. JEP 522 v JDK 26 ubral synchronizaci mezi vlákny aplikace a vlákny sběrače, takže se maximální propustnost G1 přiblížila Serialu. Nejdelší odmlky prý měl G1 lepší vždycky, protože starou generaci uklízí přírůstkově a nemusí kvůli ní zastavit celý program. Spotřeba nativní paměti klesla na srovnatelnou úroveň až v posledních vydáních.

Serial přitom nikam nemizí. JEP výslovně uvádí, že žádný sběrač se neruší ani neoznačuje za zastaralý a že ruční volba vždy přebije volbu stroje. Riziko si autoři připouštějí sami: některým aplikacím ve stísněných poměrech může Serial pořád vyhovovat víc, a pak se prostě zapne.

java -XX:+UseSerialGC -jar app.jar
java -XX:-UseCompactObjectHeaders -jar app.jar

Za tvrzením, že se propustnost, latence, paměťová stopa ani doba startu výrazně nezhorší, stojí zatím testy Oracle. JEP o nich mluví v budoucím čase jako o závazku, ne jako o hotovém měření, a nezávislé srovnání G1 se Serialem na malých haldách zveřejněné není.

Hlavička objektu se zkrátila o třetinu

Druhá změna je pod povrchem. Každý objekt na haldě si vedle vlastních dat nese hlavičku, ve které je mimo jiné ukazatel na třídu a identitní hash. Na 64bitových architekturách měřila 96 bitů, nově měří 64. Míň bitů na objekt znamená menší haldu, hustší data v cache a méně práce pro sběrač.

Šlo to po krocích. JEP 450 zavedl kompaktní hlavičky v JDK 24 jako pokusnou možnost, JEP 519 z nich v JDK 25 udělal plnohodnotnou funkci a teprve JEP 534 je zapíná ve výchozím stavu.

Čísla, kterými to dokládá, patří ke konkrétním pokusům a JEP to sám říká. V jednom nastavení ubral benchmark SPECjbb2015 22 % místa na haldě a 8 % času procesoru. V jiném nastavení klesl počet sběrů o 15 %, a to u G1 i u Parallelu. Silně paralelní rozbor JSONu doběhl o 10 % rychleji. Žádný z těch údajů se netýká všech aplikací a JEP je ani jako obecné pravidlo nepodává.

Provozní zkušenost je z druhé ruky, zato ne z Oraclu. Amazon podle JEPu běží se zkrácenými hlavičkami na stovkách služeb, většinou přes zpětné porty do JDK 21 a JDK 17, a SAP je má ve svém forku OpenJDK zapnuté ve výchozím stavu už dřív. Vypnout se dají přepínačem z ukázky výš. Starý formát hlavičky má být v některém z příštích vydání označený za zastaralý a čtyři bity z nové hlavičky jsou zarezervované pro projekt Valhalla.

Handshake TLS začne nabízet postkvantovou skupinu

Třetí změna výchozího stavu není ve stroji, ale v knihovnách. JEP 527 přidal do implementace TLS 1.3 tři hybridní schémata výměny klíčů, která kombinují klasické ECDHE s postkvantovým ML-KEM. Hybridní proto, že spojení zůstane bezpečné, dokud odolává aspoň jeden z těch dvou algoritmů.

Ve výchozím seznamu takzvaných pojmenovaných skupin stojí nově na prvním místě X25519MLKEM768, takže ho klient při navázání spojení nabídne jako první a rovnou k němu pošle klíčový podíl. Kdo si skupiny v kódu nevybírá sám, dostane postkvantovou výměnu klíčů bez jediné úpravy. Zbývající dvě schémata, SecP256r1MLKEM768 a SecP384r1MLKEM1024, zapnutá nejsou; pustí je vlastnost systému jdk.tls.namedGroups nebo metoda SSLParameters::setNamedGroups.

Šest dalších, většinou na vyzkoušení

Zbylé JEPy v seznamu funkcí JDK 27 se samy neprojeví. Pět z nich jsou náhledy nebo inkubátor, tedy věci, které se musí zapnout a jejichž podoba se ještě může posunout:

• Lazy Constants, třetí náhled
• primitivní typy ve vzorech, v instanceof a ve switch, pátý náhled
• strukturovaná souběžnost, sedmý náhled
• Vector API, dvanáctý inkubátor
• kódování PEM pro kryptografické objekty, třetí náhled

Šestý je hotový: záznamy nástroje JFR umí nově zatemnit citlivé údaje přímo v procesu, který je pořizuje.

Podpora do března

Java 27 není vydání s dlouhodobou podporou. Plán podpory Oracle, aktualizovaný týž den, jí dává Premier Support do března 2027, kdy ji nahradí Java 28. Dlouhodobou podporu drží Java 25 do září 2030 a další LTS má být Java 29 v září 2027.

Kdo tedy provoz drží na LTS, všechny tři změny výchozího chování uvidí až za rok. Zajímavé to je hlavně pro ty ostatní, a z nich zvlášť pro provoz v malých kontejnerech, na běžcích CI a na levných virtuálních strojích. Tam se po přechodu na Javu 27 vymění sběrač, aniž o to někdo požádal, a JEP sám připouští, že to nemusí být k lepšímu. Stará podoba je na jeden přepínač, ale někdo ho musí napsat.

Zdroje

• Mark Reinhold: Java 27 / JDK 27: General Availability, konference announce na openjdk.org, 15. září 2026
• JDK 27, openjdk.org
• JEP 523: Make G1 the Default Garbage Collector in All Environments
• JEP 534: Compact Object Headers by Default
• JEP 527: Post-Quantum Hybrid Key Exchange for TLS 1.3
• Oracle Java SE Support Roadmap
• Java 27 Reaches GA With The G1 Garbage Collector By Default Everywhere, Phoronix, 15. září 2026