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

[Volker Simonis]

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.

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.


> In fact, the JVM uses a thread stack size setting of 228k (the result of
> the calculation in os::init_2 which is bigger than the original set
> value of 64k in src/os_cpu/linux_x86/vm/os_linux_x86.cpp).
>
> If I build a JDK with this patch:
> diff --git a/src/os_cpu/linux_x86/vm/os_linux_x86.cpp
> b/src/os_cpu/linux_x86/vm/os_linux_x86.cpp
> --- a/src/os_cpu/linux_x86/vm/os_linux_x86.cpp
> +++ b/src/os_cpu/linux_x86/vm/os_linux_x86.cpp
> @@ -618,7 +618,7 @@
>  // thread stack
>
>  #ifdef AMD64
> -size_t os::Linux::min_stack_allowed  = 64 * K;
> +size_t os::Linux::min_stack_allowed  = 512 * K;
>  #else
>  size_t os::Linux::min_stack_allowed  =  (48 DEBUG_ONLY(+4))*K;
>  #endif // AMD64
>
> Then run the reproducer again:
> /path/to/java -Xint ZeroStackOverflowTest 1280
> It no longer stack-overflows.
>
> Something similar happens for me with a Zero JVM (which is always
> interpreted only).
>
> The JIT's seem to be doing something more and I wasn't able to reproduce
> it for them.
>
> Cheers,
> Severin
>
> [1]
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8073754/ZeroStackOverflowTest.java
>
>