jamesfredley commented on code in PR #16545:
URL: https://github.com/apache/grails-core/pull/16545#discussion_r4341829870
##########
grails-doc/src/en/guide/upgrading/upgrading80x.adoc:
##########
@@ -4837,3 +4837,39 @@ With `DISCRIMINATOR` multi-tenancy, GORM for MongoDB,
GORM for Neo4j and GORM's
* Without a current tenant, these methods throw `TenantNotFoundException`, as
a query does. `getAll` without ids still returns an empty list.
* Inside `Tenants.withoutId { }` a lookup by id is still not restricted to a
tenant, and neither is a proxy returned by `load` or `proxy` that is
initialized there. As the previous note says, only `withoutId` lifts the
restriction: a tenant id of `default` restricts a lookup by id to that tenant
as it restricts a query.
* A lookup by id still finds an instance that the session holds for the
current tenant, including one that has been saved but not flushed, and it does
not flush the session.
+
+
+[[java25-memory-upgrade]]
+==== 88. Java 25 Memory Requirements
+
+Grails 8 supports Java 25 (the next LTS after Java 21).
+Both Java 21 and Java 25 leave metaspace unlimited by default unless you set
an explicit ceiling with `-XX:MaxMetaspaceSize`; this default has been
unchanged since JDK 8.
+On both versions, `-XX:MetaspaceSize` sets the initial high-water mark that
triggers garbage collection, not a limit on metaspace growth. The JVM adjusts
this threshold according to metadata usage.
+
+A Grails application loads a large number of classes — plugins, Hibernate
entity mappings, GSP-compiled views, Spring beans — so metaspace can account
for a significant part of the process's native memory on either JDK.
+In a container environment this is especially important: the heap limit
(`-Xmx` or `-XX:MaxRAMPercentage`) does not cover metaspace, so a container
sized only for the heap can be killed by the container runtime's OOM killer
when metaspace grows beyond the remaining native memory budget.
+
+**What to do when running on Java 25:**
+
+Set an explicit metaspace ceiling with `-XX:MaxMetaspaceSize` so the JVM
raises `OutOfMemoryError: Metaspace` before the container runtime kills the
process:
+
+[source,bash]
+----
+java -Xmx512m -XX:MaxMetaspaceSize=256m -Dgrails.env=prod -jar application.jar
+----
+
+Or, using percentage-based heap sizing in a container:
+
+[source,bash]
+----
+java -XX:MaxRAMPercentage=60.0 -XX:MaxMetaspaceSize=256m -Dgrails.env=prod
-jar application.jar
+----
+
+Tune `-XX:MaxMetaspaceSize` from a measured baseline: run the application
under representative load, observe metaspace usage with `jcmd <pid>
VM.metaspace`, and add a safety margin.
+
+The `-XX:+/-UseCompressedClassPointers` flag is deprecated in Java 25 and will
be removed in a future release.
+
+* If your startup scripts pass `-XX:+UseCompressedClassPointers` (the
default), remove it — it is superfluous.
+* If they pass `-XX:-UseCompressedClassPointers` to disable compressed class
pointers, remove it.
Review Comment:
Do not tell people to remove `-XX:-UseCompressedClassPointers`
unconditionally. That flag is deprecated in Java 25, but it still works. An
application that set it to avoid the compressed class space keeps a single
class-pointer space. Removing it turns compressed class pointers back on and
can bring back `OutOfMemoryError: Compressed class space` under the same
`MaxMetaspaceSize`.
Say to remove `-XX:+UseCompressedClassPointers` because it is the default.
For the minus form, say it is deprecated and scheduled for removal, and that
dropping it changes the memory layout and has to be checked against the
measured class-space use. Do not equate it with the redundant positive flag.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
