RFR(XS): 8073754: Zero/PPC: StackOverflowError during build in javadoc processing.

[Severin Gehwolf]

Hi David,

Thanks for the review!

On Thu, 2015-07-30 at 14:49 +1000, David Holmes wrote:
> Hi Severin,
> 
> On 29/07/2015 11:09 PM, Severin Gehwolf wrote:
> > Hi,
> >
> > Could somebody please review and sponsor this Zero-only change?
> >
> > It fixes a build problem of OpenJDK 9 Zero on PPC64. That architecture
> > seems to be notoriously stack hungry and needs an increased minimal
> > stack in order to build and self-build JDK 9.
> >
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8073754
> > Webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8073754/webrev.02/
> 
> src/os_cpu/linux_zero/vm/os_linux_zero.cpp
> 
> I'm not clear how this:
> 
> size_t os::Linux::min_stack_allowed = 2240 * K;
> 
> relates to all the values specified in the header file ??

You see the relationship in os::init_2 (src/os/linux/vm/os_linux.cpp).
The user set ThreadStackSize has to be >= os::Linux::min_stack_allowed.
Otherwise the JVM fails to initialize. In the Zero PPC case,
os::Linux::min_stack_allowed as defined in
src/os_cpu/linux_zero/vm/os_linux_zero.cpp > than the calculation
involving yellow, red, shadow pages et. al. done in os::init_2.

If we'd keep ThreadStackSize at 1536 KB for PPC64 Zero then the JVM
would not initialize.

As to the VMThreadStackSize settings, I'm not 100% sure they are needed.

> Overall changing the default stacksizes for all threads this way seems 
> somewhat excessive to me - do you really need it for every Java 
> application? If builds are just the issue, and javadoc invocations in 
> particular, I would adjust the build settings.

Understood. Do we really need it for every Java application? No,
probably not, but is there a way to fix programs who think they know the
stack size setting better than then JVM? For an example see the program
below.

The reproducer I've been using was something like this (extracted from
the build.log):
/path/to/boot/jdk/bin/java -Xms64M -Xmx1600M "-Xbootclasspath/p:/priv/sgehwolf/openjdk9-hs-rt/build/linux-ppc64-normal-zero-release/buildtools/interim_langtools.jar" -cp /priv/sgehwolf/openjdk9-hs-rt/build/linux-ppc64-normal-zero-release/buildtools/interim_langtools.jar com.sun.tools.javac.Main -source 9 -target 9 -encoding ascii -XDignore.symbol.file=true -Xlint:all -Werror -g -Xdoclint:all/protected,-reference '-Xdoclint/package:java.*,javax.*' -bootclasspath /priv/sgehwolf/openjdk9-hs-rt/build/linux-ppc64-normal-zero-release/support/empty-dir -classpath ":/priv/sgehwolf/openjdk9-hs-rt/build/linux-ppc64-normal-zero-release/jdk/modules/java.base" -Xdoclint:all/protected,-reference '-Xdoclint/package:java.*,javax.*' -implicit:none -d /priv/sgehwolf/openjdk9-hs-rt/build/linux-ppc64-normal-zero-release/jdk/modules/java.base.test -h /priv/sgehwolf/openjdk9-hs-rt/build/linux-ppc64-normal-zero-release/support/headers/java.base.java.base.tmp @/priv/sgehwolf/openjdk9-hs-rt/build/linux-ppc64-normal-zero-release/jdk/modules/java.base/_the.java.base_batch

In fact this is batch-compiling the jdk.base module which stack
overflows on PPC64 with an OpenJDK 8 Zero boot jdk. I should probably
change the bug synopsis. Adding settings like -XX:ThreadStackSize=2240
-XX:VMThreadStackSize=1600 did not work for me.

Why? I can only speculate. We've had stack overflow issues before where
Java programs similar to the one attached caused it. I.e. specifying the
stack size via Thread's constructor. That led me to believe that we
might have a similar problem here. Note that specifying ThreadStackSize
on the command line has no effect for programs like these. For such code
min_stack_allowed comes into play and that's what I think is happening
here.

Thanks,
Severin