Dear Maintainer,
On a certain multi-user system, I have the following lines in /etc/profile ...
ulimit -d 999999
ulimit -v 3899999
In other words, almost 4G virtual memory per process, of which 1G data segment. (Physical RAM is currently 16G.)
But with those settings, and the Java runtime default memory alocation, Java does not start. Even "java -help"
or "java -version" fails with a memory error!
$ java -version
Error occurred during initialization of VM
Could not allocate compressed class space: 1073741824 bytes
Now, I can pass an argument to limit Java heap size, and it works:
$ java -Xmx1500m -version
openjdk version "17.0.6" 2023-01-17
OpenJDK Runtime Environment (build 17.0.6+10-Debian-1deb11u1)
OpenJDK 64-Bit Server VM (build 17.0.6+10-Debian-1deb11u1, mixed mode, sharing)
But there's a point where it gets weird:
$ java -Xmx1750m -version
openjdk version "17.0.6" 2023-01-17
OpenJDK Runtime Environment (build 17.0.6+10-Debian-1deb11u1)
OpenJDK 64-Bit Server VM (build 17.0.6+10-Debian-1deb11u1, mixed mode, sharing)
$ java -Xmx1800m -version
[0.019s][warning][os,thread] Failed to start thread "Unknown thread" - pthread_create failed (EAGAIN) for attributes: stacksize: 1024k, guardsize: 0k, detached.
Error occurred during initialization of VM
$ java -Xmx1900m -version
Error occurred during initialization of VM
Could not allocate compressed class space: 1073741824 bytes
Or if I adjust the "ulimit -v" limit downward, the safe-start point of the Java VM goes down, but not one-for-one...
$ ulimit -v 3699999
$ java -Xmx1750m -version
Error occurred during initialization of VM
Could not allocate compressed class space: 1073741824 bytes
$ java -Xmx1650m -version
openjdk version "17.0.6" 2023-01-17
OpenJDK Runtime Environment (build 17.0.6+10-Debian-1deb11u1)
OpenJDK 64-Bit Server VM (build 17.0.6+10-Debian-1deb11u1, mixed mode, sharing)
Upstream bug https://bugs.openjdk.org/browse/JDK-8071445 . Last comment:
But the "obvious workaround" is not always straightforward when using applications or tools built on Java (e.g., Eclipse or Gradle).
The JDK already checks whether it's in a Docker container and adjusts its memory allocation strategy accordingly,
see https://www.oracle.com/java/technologies/javase/8u191-relnotes.html#JDK-8146115 .
If no memory-tuning arguents are passed in and "ulimit -v" is in effect (getrlimit(RLIMIT_AS, ...) ),
the JDK should find a memory structure that fits within the available memory, or give a friendlier
error-message if it can't.
(If -Xms and -Xmx both set, and the initial allocation would succeed but the maximum allocation would fail,
maybe Java should print a warning.)