javac stack overflow on loongson3 with zero variant

[Bingwu Zhang]

Hi!

Recently when packaging OpenJDK 24-ga for AOSC OS, I hit an compilation error 
on loongson3 (which is a variant of mips64), saying that javac is running out 
of stack space:

> 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/
com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:50)
> 	at jdk.compiler.interim/
com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:463)
> 	at jdk.compiler.interim/
com.sun.tools.javac.comp.Flow$AssignAnalyzer.scan(Flow.java:2097)
> 	at jdk.compiler.interim/
com.sun.tools.javac.comp.Flow$AssignAnalyzer.scanCond(Flow.java:2382)
> 	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)
>    ... (rest of output omitted)

For the full build log, please see the log of our build system [1].

We use zero variant for loongson3 currently (and it is the only architecture 
we supported using zero).
As it build on other architectures properly, I think it is likely just because 
the default stack size is too small, unlikely to be a dead loop in javac. I 
attempted to add "--with-boot-jdk-jvmargs=-Xss256M" to extend the thread stack 
size but it changed nothing.

The configure command is:
> bash configure --with-jvm-variants=zero --enable-precompiled-headers --with-
boot-jdk-jvmargs=-Xss256M --with-conf-name=aosc --with-stdc++lib=dynamic --
disable-warnings-as-errors --enable-linktime-gc --with-native-debug-
symbols=zipped

What should I try next? Is this a bug or a even larger stack is required?

[1] https://buildit.aosc.io/logs/73789-openjdk-24-loongson3-Misaka23333-2025-03-22-03:32:47.txt

-- 
Bingwu Zhang (@xtex) @ Fri, 21 Mar 2025 23:12:49 +0000