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

[Severin Gehwolf]

On Thu, 2015-07-30 at 13:25 +0200, Severin Gehwolf wrote:
> 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.

Hmm, mailing list scraped attachment. Here is a link to it:
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8073754/ZeroStackOverflowTest.java

Cheers,
Severin