# JEP 475 : Late Barrier Expansion for G1

#### [JEP 475](https://openjdk.org/jeps/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."
