( Artigo publicado em: https://medium.com/@guilherme.zarelli/java-25-compact-object-headers-jep-519-efici%C3%AAncia-impactos-e-aplica%C3%A7%C3%B5es-f7d6a7324621 )
Compact Object Headers, introduzidos de forma experimental no Java 24 (JEP 450) e promovidos a recurso de produção no Java 25 (JEP 519), otimizam a representação dos metadados dos objetos na memória, reduzindo o tamanho do header e aumentando a eficiência de cache. Essa melhoria beneficia aplicações com milhões de objetos pequenos, reduzindo consumo de memória e pressão no GC, além de potencialmente melhorar latência e throughput.
A sobrecarga de memória por objeto impacta diretamente aplicações que manipulam muitos objetos pequenos, como DTOs, eventos e modelos ricos. Com heap pressionado ou alta taxa de alocação, qualquer ganho por objeto reduz o impacto do coletor de lixo e melhora a localidade de dados.
"This feature is particularly beneficial when applications allocate many small objects." — JEP 450
- Menor consumo de memória por objeto — o header típico cai de 12 bytes para 8 bytes, o que tende a economizar ~4 bytes por objeto em heaps com compressed class pointers.
- Melhor eficiência de cache — mais objetos por cache line.
- Menos pressão de GC; menos ciclos curtos.
- Menor footprint em containers com limites de memória.
- O impacto positivo tende a ser mais perceptível em coletores regionais (G1, ZGC) que se beneficiam diretamente de menor live data por região.
"Reducing the amount of live data can lower GC pressure and improve performance on allocation-heavy workloads." — GC Tuning
+-------------------------------+
| Mark Word (64 bits) |
| Klass Pointer (32 bits) | 96 bits ≈ 12 bytes
+-------------------------------+
| Padding / alinhamento | (leva o objeto mínimo para 16 bytes)
+-------------------------------+
| Dados do Objeto... |
+-------------------------------+
| Compact Header (64 bits) | 64 bits = 8 bytes
+-------------------------------+
| Dados do Objeto... |
O Compact Header combina Mark Word e Klass Pointer de forma otimizada, reduzindo espaço total.
java -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders ...java -XX:+UseCompactObjectHeaders ...java \
-XX:+UseCompactObjectHeaders \
-Xlog:gc*,safepoint:file=gc.log:tags,uptime,time \
-jar app.jarPara validar se o uso de Compact Object Headers realmente reduziu o número de bytes ocupados pelos objetos em memória, você pode medir o heap antes e depois de aplicar uma carga de trabalho. O objetivo não é medir GC ou throughput diretamente, mas sim observar se a densidade de objetos aumentou e se o heap está menos pressionado.
Passos recomendados:
- Inicialize a aplicação com
-XX:+UseCompactObjectHeaders. - Gere uma carga que crie e mantenha objetos em memória (ex.: processar mensagens, requests, eventos).
- Capture a distribuição de classes e o tamanho ocupado por elas antes e depois da execução.
# capturar histograma vivo de objetos
jmap -histo:live <pid> | head -20
# obter histograma antes da carga
jcmd <pid> GC.class_histogram > before.txt
# ... executar carga de trabalho que cria muitos objetos ...
jcmd <pid> GC.class_histogram > after.txtComo interpretar:
- Compare
before.txteafter.txtobservando as colunas Bytes e Instances. - Se Compact Object Headers estiver ajudando, o total de Bytes deve ser menor para uma quantidade semelhante de Instances, indicando que o header reduzido aumentou a densidade de objetos.
- Essa medição é mais confiável sob cenários controlados, com pouca variação estrutural no heap além da compactação.
- Para isolar o efeito da compactação, execute a mesma carga em dois runs:
um com e outro sem
-XX:+UseCompactObjectHeaders, comparando os histograms finais.
| Tipo de aplicação | Adotar? | Benefício | Observações |
|---|---|---|---|
| Microserviços com milhões de DTOs | Sim | Alto | Reduz impacto do GC e melhora localidade |
| Streaming / mensageria | Sim | Alto | Grandes coleções de objetos pequenos |
| Aplicações batch de buffers grandes | Talvez | Baixo | Objetos grandes diluem ganho |
| Workloads ML | Não | Baixo | Dados nativos dominam; ganhos mínimos em objetos Java |
| Serviços com lock frequente em objetos | Cautela | Variável | Em cenários com muito synchronized e uso intenso de identityHashCode, parte do ganho de memória pode ser reduzido por conta de monitores inflados e metadados extras. |
"Limited gains are expected when large objects dominate the heap or when locking and identity hash are used extensively." — JEP 519
"Improved memory usage can be reduced when object identity hash codes or inflated monitors are required." — JEP 450
- hashCode baseado em identidade pode exigir estruturas auxiliares.
System.identityHashCode()continua funcionando, mas usa menos bits internamente. Em objetos muito disputados (hash + lock), o runtime pode associar monitores externos, reduzindo o ganho líquido de memória nesses objetos, mas sem expandir o header para 12 bytes novamente. - Sincronização explícita também pode inflar.
- Em workloads com objetos grandes, ganho é mínimo.
- Ferramentas de inspeção de memória precisam estar atualizadas.
- Limite de classes: com COH ligado há limite de ~4 milhões de classes carregadas; acima disso, a feature não é suportada.
| Dimensão | Impacto Potencial | Observações Técnicas |
|---|---|---|
| Memória | Redução significativa em objetos pequenos | Header cai de ~12 para ~8 bytes, aumentando densidade de dados. Ganho típico de heap vivo reportado: 10%–20% em workloads orientados a objetos pequenos. |
| CPU | Pode reduzir uso de CPU | Ganho indireto: menos live data → menos trabalho do GC. Benchmarks reportam até 30% de redução de CPU em cenários GC/alloc-bound. Para workloads CPU-bound sem pressão de heap, o ganho é pequeno. |
| Latência | Pode reduzir pausas curtas do GC | Efeito depende do coletor e do volume de pequenas alocações. Menos coleções jovens → menos interrupções de baixa latência; impacto menor se a aplicação não é GC-sensível. |
| Throughput | Pode melhorar em cenários GC/alloc-bound | SPECjbb reporta ~8% de melhora quando o heap pode ser reduzido mantendo mesmo throughput. Não é garantia: se o bottleneck é I/O, rede ou CPU puro sem alocação pesada, ganho tende a zero. |
"Benchmark results indicated throughput improvements and reduced live heap when the heap size was lowered without impacting performance." — Oracle Blog
- Muitos objetos pequenos vivos no heap.
- Heap pressionado e GC frequente.
- Tráfego alto de eventos e DTOs.
- Containers com limites de memória rígidos.
"The reduction in header size is especially effective when many small objects form the majority of the live data set." — GC Tuning
Compact Object Headers entregam um ganho efetivo em aplicações onde o volume de objetos pequenos domina o heap. A compactação aumenta a densidade de dados no cache e reduz a pressão no GC, impactando diretamente latência e throughput. No entanto, cenários com uso intenso de identityHashCode() ou locking podem perder parte do benefício para esses objetos específicos; o restante do heap continua se beneficiando da compactação, e aplicações dominadas por objetos grandes não se beneficiam.
"The effect is amplified when the reduction in live data allows the heap size to be lowered without compromising throughput." — Oracle Blog
- JEP 519 — Compact Object Headers: https://openjdk.org/jeps/519
- Oracle JDK 25 Release Notes: https://www.oracle.com/br/java/technologies/javase/25-relnote-issues.html
- GC Tuning — Compact Object Headers: https://docs.oracle.com/en/java/javase/25/gctuning/other-considerations.html
- The Arrival of Java 25 — Oracle Blog: https://blogs.oracle.com/java/post/the-arrival-of-java-25
- Java 25 Integrates Compact Object Headers — InfoQ: https://www.infoq.com/news/2025/06/java-25-compact-object-headers
- Reduce Object Header Size — Baeldung: https://www.baeldung.com/java-object-header-reduced-size-save-memory