Increase the default thread stack size of zero

[Bingwu Zhang]

Hi!

When I was packaging OpenJDK 24-GA for AOSC OS, I got an compilation error 
from our loongson3 build server, saying that javac is running out of stack 
space [1]. loongson3 is a variant of MIPS, using target triple "mips64el-
linux-gnuabi64". It has no JIT support and zero is the only variant supporting 
it.

> java.lang.StackOverflowError
> 	at jdk.compiler.interim/
> com.sun.tools.javac.code.Type.constValue(Type.java:186)
> 	at jdk.compiler.interim/
> com.sun.tools.javac.code.Type$JCPrimitiveType.isFalse(Type.java:823)
> 	at jdk.compiler.interim/
> com.sun.tools.javac.comp.Flow$AssignAnalyzer.scanCond(Flow.java:2365)
> 	at jdk.compiler.interim/
> com.sun.tools.javac.comp.Flow$AssignAnalyzer.visitBinary(Flow.java:3181)
> 	at jdk.compiler.interim/
> com.sun.tools.javac.tree.JCTree$JCBinary.accept(JCTree.java:2221)
> 	at jdk.compiler.interim/

The configure command (for JDK 25) is:
> bash configure --with-jvm-variants=zero --enable-precompiled-headers --with-
> boot-jdk-jvmargs=-Xss256M --with-stdc++lib=dynamic --with-boot-jdk=/usr/
lib64/
> java-24 --with-conf-name=build1 --with-debug-level=fastdebug
> bash configure --with-jvm-variants=zero --enable-precompiled-headers --with-
> boot-jdk-jvmargs=-Xss256M --with-stdc++lib=dynamic --with-boot-jdk=$(pwd)/
> build/build1/jdk --with-conf-name=build2 --with-debug-level=fastdebug

- This error only occurs when compiling natively (where the bootstrap JDK is 
also a zero one), not when cross-compiling from x86-64 (not zero).
- It is reproducible.
- Disabling javac server did not help.
- It still exists in JDK 25. (patched 24 -> unpatched 25 -> fails to build 25)

It first appeared when I was upgrading from 24+32 to 24-GA, so I bisected 
between them [2]. The first bad commit is:
15ae8d02eeb9 (8319993: Update Unicode Data Files to 16.0.0 8319992: Update 
ICU4J to Version 76.1, 2024-11-25)
This commit looked innocent but reverting it did fixed build.

A deeper investigation pointed to the default thread stack size being too 
small. On MIPS, glibc uses a 2MiB stack by default [3], while many Linux 
distributions overwrite the default size with 8MiB using ulimit. However, the 
default of OpenJDK has been 1.5MiB for Java threads and 1MiB for VM threads 
since 17 years ago [4].

Throughout the years, architectures, OpenJDK and Java applications have 
developed quickly, making the old value insufficient. Thus I think it is time 
to increase the default size. Last year I increased the default stack size on 
AOSC OS to 6MiB/4MiB and JDK built successfully.

According to the contributing guide, I am writing to socialize my change and 
request for some comments.

I also have some questions:
- How large should the default stack size be? I think 6MiB/4MiB (4 times of 
the old) is enough, although it is even larger than on some architectures with 
JIT. Maybe 2MiB/2MiB if we want to match other architectures or glibc?
- Does this change need a CSR review? I don't think increasing stack size 
could break anything, except for some applications that expect 
StackOverflowException being thrown at a certain call depth (Sorry, I failed 
to find a real-world example). Patched versions of OpenJDK have been shipped 
to AOSC OS users using loongson3 (6MiB/4MiB, JDK 8/11/17/20-24) and I haven't 
received any bug report related to this in the past one year.
- Does this change need new regression tests? I think it is unnecessary 
because 1) it is hard to check the effective stack size, and 2) when the size 
is insufficient again, builds will start failing, telling people to increase 
again.
- Should we just let the build scripts set the stack size instead of changing 
the default? I do think the current default is too small, and failed to find a 
way to pass the stack size to build scripts. But if you think it is better 
to just change the build scripts, that's fine for me.

With respect to the side-effects of this change, I did some tests with 24-GA 
last year. The configuration is: 6MiB/4MiB, 2x 3B4000 @ 1.8GHz, 32 GiB 
physical RAM. Theoretically speaking, I thought increasing the 
default stack size would increase the memory usage. However, after running 
jcstress repeatedly, I did not observe an increase in the total memory usage, 
except for normal tiny differences between runs.
Maybe the differences were hidden due to the heap allocator's over-allocating? 
I don't know.

Please let me know if anyone is interested in this change or have any 
suggestions! Thank you!

[1] https://mail.openjdk.org/pipermail/build-dev/2025-March/049679.html 
(previous thread)
[2] https://mail.openjdk.org/pipermail/build-dev/2025-April/050018.html 
(previous bisection)
[3] https://sourceware.org/cgit/glibc/tree/sysdeps/mips/nptl/pthreaddef.h?
h=glibc-2.43&id=f762ccf84f122d1354f103a151cba8bde797d521#n19
[4] https://github.com/openjdk/jdk/blob/
5152fdcd490412025ba5f608378982abc1eadc07/src/hotspot/os_cpu/linux_zero/
globals_linux_zero.hpp#L34-L36

-- 
Bingwu Zhang (a.k.a. xtex, @xtexx on GitHub) @ Sat, 07 Feb 2026 08:22:24 +0000
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 265 bytes
Desc: This is a digitally signed message part.
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20260207/cfdf3d68/signature.asc>