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

[Severin Gehwolf]

On Fri, 2015-07-31 at 17:04 +0200, Volker Simonis wrote:
> 
> 
> On Thu, Jul 30, 2015 at 6:05 PM, Severin Gehwolf <sgehwolf at redhat.com>
> wrote:
>         On Thu, 2015-07-30 at 16:52 +0200, Severin Gehwolf wrote:
>         > > >> If a normal thread doesn't honor the
>         -XX:ThreadStackSize settings I'd
>         > > >> consider that a bug and fix that one first.
>         > > >
>         > > > By fixing it you mean in jdk or hotspot code? Any
>         suggestions?
>         > > >
>         > >
>         > > I mean in the hostspot code. But of coarse only if the
>         above tests
>         > > show that the settings are not honored by the VM.
>         >
>         > OK.
>         
>         So I did more experimentation with this and here is what I
>         found. Any
>         JVM with -Xint fall back to the bigger of
>         os::Linux::min_stack_allowed
>         as set in src/os_cpu/linux_$CPU/vm/os_linux_$CPU.cpp and the
>         following
>         calculation coming from os::init_2 for the reproducer in [1]:
>         
>         MAX2(os::Linux::min_stack_allowed,
>                   (size_t)(StackYellowPages+StackRedPages
>         +StackShadowPages) * Linux::page_size() +
>                   (2*BytesPerWord COMPILER2_PRESENT(+1)) *
>         Linux::vm_default_page_size());
>         
>         It can be fairly easy reproduced with:
>         http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8073754/ZeroStackOverflowTest.java
>         
>         The following produces a stack overflow for me on x86_64:
>         /path/to/java -Xint ZeroStackOverflowTest 1280
>         If I change this to:
>         /path/to/java -Xint -XX:ThreadStackSize=2028
>         ZeroStackOverflowTest 1280
>         nothing changes. I.e. the stack overflow still happens at
>         ~1266'th call.
>         
> 
> 
> I don't understand what you want to prove with this test. If you
> create a thread yourself with a given stack size (like in your
> example) then of course the -XX:ThreadStackSize setting will have no
> impact. That's exactly how it should work if YOU specify the stack
> size in the Thread constructor.

Sorry, I confused your statement it seems: "If a normal thread doesn't
honor the -XX:ThreadStackSize settings I'd consider that a bug and fix
that one first."

I took the above as "a thread created with the 4-arg constructor should
honor -XX:ThreadStackSize as well". That it does not (apparently by
design). Nevertheless, it seems nonsense to me to specify the stack size
via Java code since it seems rather JVM specific. Some JDK code does
that.

> I took your reproducer and run it in a Java debugger with a breakpoint
> in java.lang.Thread.<init>. I only see that the various compiler
> threads and the sweeper and service threads are created - all of them
> without specifying a thread size.
> 
> 
> I've also run your reproduce in gdb with a breakpoint in
> os::create_thread(). Here you will see all the threads which are
> created by the VM (including the main thread) and all of them are
> created with 'stack_size=0' which means default stack size. For
> Java-threads, the default stack size is the one you give with
> -Xss/-XX:ThreadStackSize
> 
>       case os::java_thread:
>         // Java threads use ThreadStackSize which default value can be
>         // changed with the flag -Xss
>         assert(JavaThread::stack_size_at_create() > 0, "this should be
> set");
>         stack_size = JavaThread::stack_size_at_create();
>         break;
> 
> 
> If this is not working for Zero you should analyze that problem.
> 
> 
> But your reproducer is definitely not creating a Java thread with a
> custom stack size.

Fair enough. I'll have another look. Thanks for your feedback.

Cheers,
Severin