[
https://issues.apache.org/jira/browse/GROOVY-12142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18105755#comment-18105755
]
ASF GitHub Bot commented on GROOVY-12142:
-----------------------------------------
blackdrag commented on code in PR #2798:
URL: https://github.com/apache/groovy/pull/2798#discussion_r3809459596
##########
src/spec/doc/guide-integrating.adoc:
##########
@@ -378,6 +378,43 @@ stub generation is done, for the joint compiler.
However, overriding `CompilationUnit` is not recommended and should only be
done if no other standard solution works.
+== Class loader release in managed environments
+
+Applications that load and discard Groovy repeatedly — a web container
performing (parallel)
+redeployments with Groovy inside each web application, plugin systems, or any
host that expects
+class loaders to be garbage collected — need one extra consideration.
+
+Groovy associates runtime metadata (`ClassInfo`) with every class it
dispatches on, including
+JDK classes such as `String`. By default those associations use
`java.lang.ClassValue`, which
+gives the fastest possible lookup, but a long-standing JVM issue
+(https://bugs.openjdk.org/browse/JDK-8136353[JDK-8136353]) prevents such
associations on
+long-lived classes from ever releasing their value — and with it the Groovy
class loader the
+value belongs to. In a container this shows up as metaspace growth on every
redeployment, even
+after the old application is undeployed.
+
Review Comment:
+1
> Metaspace memory leak with parallel deployments on Tomcat
> ---------------------------------------------------------
>
> Key: GROOVY-12142
> URL: https://issues.apache.org/jira/browse/GROOVY-12142
> Project: Groovy
> Issue Type: Bug
> Affects Versions: 4.0.24, 4.0.29, 5.0.8, 5.1.0, 6.0.0-beta-2
> Environment: Tomcat: 10.1.55
> openjdk version "17.0.19" 2026-04-21 LTS
> OpenJDK Runtime Environment (Red_Hat-17.0.19.0.10-1) (build 17.0.19+10-LTS)
> OpenJDK 64-Bit Server VM (Red_Hat-17.0.19.0.10-1) (build 17.0.19+10-LTS,
> mixed mode, sharing)
> Reporter: Jan Gosmann
> Assignee: Paul King
> Priority: Major
> Fix For: 6.0.0-beta-3
>
> Attachments: Screenshot 2026-07-09 at 09.46.46.png, spring-test.tar.gz
>
>
> We are using [Tomcat parallel
> deployments|https://tomcat.apache.org/tomcat-10.0-doc/config/context.html#Parallel_deployment]
> to achieve downtimeless deployments. However, we with each new deployment
> the metaspace grows (see attached image). Even after undeploying the old
> version it does not shrink. If we configure a maximum metaspace size, new
> parallel deployments fail with an out-of-memory error.
> I was able to reproduce this with a very simple Spring Boot application
> (attached). As long as I had no Groovy in there, metaspace was reclaimed
> before hitting the maximum on new deploys. After introducing Groovy,
> metaspace is no longer reclaimed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
