JVM: CodeCache is full. Compiler has been disabled

Fix the JVM "CodeCache is full" warning and falling throughput by sizing ReservedCodeCacheSize and finding code-generation leaks.

advanceddebuggingjavajvmperformance

Symptoms

Java HotSpot(TM) 64-Bit Server VM warning: CodeCache is full. Compiler has been disabled.
Throughput degrades over hours and no more methods are JIT-compiled
The warning repeats, then CPU stays low while latency rises

Possible causes

ReservedCodeCacheSize is too small for the workload (default ~240MB tiered)
Dynamic class generation (proxies, lambdas, scripting) leaks compiled code
A class loader leak accumulates generated classes indefinitely
A large application compiles a very high number of methods

Diagnosis steps

Watch the code cache usage

jcmd <pid> PerfCounter.print | grep codecache

Interpretation

Steadily rising code cache with no reclaim indicates a full or leaking cache.

Check for class loader growth

jcmd <pid> GC.class_stats  # or a heap dump analysis

Interpretation

Growing class loader counts point to dynamic generation that never unloads.

Correlate with dynamic proxy or scripting use

Interpretation

Frameworks that generate proxies per call can exhaust the cache under specific traffic.

Root cause

The JVM stores JIT-compiled methods in a fixed-size code cache (ReservedCodeCacheSize). When it fills, the compiler is disabled to protect the process; existing methods still run interpreted or compiled, but new ones are never optimised, so throughput collapses. Dynamic class generation that is never unloaded accelerates this.

Fix

Increase -XX:ReservedCodeCacheSize for large workloads and keep -XX:+UseCodeCacheFlushing enabled so stale segments can be reclaimed. Reduce dynamic code generation: cache proxies, avoid creating class loaders per request, and bound scripting engines. Monitor the code cache as a first-class metric.

Verify the fix

After raising the size and removing generation leaks, the "CodeCache is full" warning stops appearing and jcmd codecache counters plateau below the limit while throughput stays stable over a long run.

Symptoms

The JVM logs CodeCache is full. Compiler has been disabled, then request latency climbs while CPU falls because no new methods are being JIT-compiled. It usually appears after hours of steady traffic.

Diagnosis

Watch the code cache and class loaders:

jcmd $(pgrep -f myapp.jar) PerfCounter.print | grep -i codecache

A counter that reaches the reserved limit and never drops confirms the cache is full; a growing class-loader count suggests generated classes are leaking.

Fix

Size the cache and stop generation leaks:

java -XX:ReservedCodeCacheSize=512m -XX:+UseCodeCacheFlushing -jar app.jar

Cache dynamic proxies, avoid a new class loader per request, and bound any runtime scripting.

Verification

Run under sustained load; the warning no longer appears, the code cache counter plateaus below the new limit, and throughput remains stable instead of degrading.