Groovy 4 GroovyClassLoader cache change: dynamic scripts still grow heap in long-running JVM

The short answer: the cache is per-loader, not static, and clearCache() cannot unload classes. The durable fix for high-volume untrusted compilation is a short-lived child GroovyClassLoader per script version that you discard completely, not a shared loader with unique names.

1. Recompiling a changed script with a shared loader

A GroovyClassLoader keeps an instance-scoped cache keyed by class name. If you call GroovyShell.parse again with changed source but the same script class name, the loader returns the previously defined class — you get stale behavior, not a redefinition. There is no supported "replace this class" operation on a shared loader. Your two real options are:

• Unique class names per version. Derive the script class name from a content hash or monotonic counter (for example via a custom CompilerConfiguration script base / naming strategy). This makes recompilation work, but every version stays loaded forever in that one loader — see the caveat below.
• A fresh child loader per script version. Parent it to a shared base loader so JDK and Groovy classes are stable, compile the script, run it, then drop every reference. This is the only option that actually bounds memory.

2. Does clearCache() release the classes?

No, not by itself. clearCache() empties the loader's internal name-to-class map, but JVM class unloading only happens when the defining ClassLoader itself becomes unreachable. If your application still holds script instances, Class objects, or — the classic trap — closures (which capture their defining class), the loader and every class it ever loaded stay alive. Groovy's metaclass/ClassInfo registry can also retain classes; reference strength there has changed across releases, so eviction behavior is version-sensitive within the 4.x line. Treat clearCache() as a hygiene step before discarding a loader, never as a substitute for discarding it.

3. Per-loader or global cache?

The class cache is per-loader. The growth people attribute to a "static cache" usually comes from two other places: (a) accumulating loader instances, each of which pins all its classes, and (b) the shared metaclass registry. So creating a fresh GroovyShell per compilation leaks via loader accumulation; reusing one loader leaks via its ever-growing class table. Neither bounds memory on its own.

Recommended pattern

1. Create one long-lived base GroovyClassLoader.
2. For each script version, create a child loader with the base as parent, compile and execute there.
3. When the script is superseded or finished, null out all references — instances, classes, closures, cached results — optionally call clearCache() on the child, and let the whole child loader be garbage-collected.

Note that the pressure point is Metaspace as much as heap: every compiled script class consumes Metaspace, reclaimed only when its loader is collected. Unique names on a shared loader therefore just trade fast growth for slow single-loader growth — acceptable for a handful of trusted scripts, wrong for thousands of user-supplied ones.

Verification plan

Your loop-and-watch approach is right, but measure the correct things:

• Track loaded-class count and Metaspace (jcmd <pid> VM.classloader_stats or JFR), not just old-gen heap.
• After discarding a child loader and all references, force a full GC and confirm with -verbose:class or a heap dump that the script classes unloaded. If they didn't, walk the GC roots — a retained closure or ClassInfo entry is the usual culprit.
• Confirm the stale-class behavior directly: compile script A, run it, recompile changed source under the same name in a shared loader, observe the old behavior; repeat with unique names to confirm the difference.

One caveat: exact clearCache() semantics and ClassInfo reference strength vary across Groovy 4.x minor releases, so pin and check the version in your dependency tree before relying on any eviction behavior. Separately, compiling untrusted scripts raises sandboxing and resource-exhaustion concerns beyond memory that this answer does not cover.