JEP 475 : Late Barrier Expansion for G1

JEP 475 <-— HERE EVERYTHING IS EXPLAINED. With Diagrams. I don't know how to show it with code.

Developers

🧠 What’s the problem?

In G1 GC, write barriers are added whenever object fields are updated. These barriers are expanded early by the JIT (C2 compiler), resulting in:

• ⏱️ More CPU time spent during compilation

• 🧠 More memory usage by the compiler

• 🐢 Slower startup and warmup, especially in cloud environments

Each G1 barrier becomes 100+ IR nodes and ~50 x86 instructions — per field write!

✅ What JEP 475 changes

It delays the expansion of G1 barriers until the last possible moment during JIT compilation.

This gives the compiler a chance to:

• 🧹 Eliminate unnecessary barriers

• 🧠 Optimize barrier code better

• 🚀 Reduce compilation overhead

💡 Why it matters (especially for cloud)

• 🔄 Faster warmup and smaller JIT footprint

• 💻 Less CPU & memory overhead from compilation

• ☁️ Better fit for short-lived apps, microservices, and containers

---

🧪 TL;DR for Devs

"JEP 475 makes the JIT smarter about G1 barriers — reducing JVM overhead without changing your code."