RFR(M): 8169373: Work around linux NPTL stack guard error.

[David Holmes]

Hi Goetz,

On 15/11/2016 3:12 AM, Lindenmaier, Goetz wrote:
> Hi David,
>
>> Did you really intend to increase the real minimum stack from 128K to
>> 256K ? (on a 64K page system)
> I finally figured why I have to set such high minimum values.
>
> A CompilerThread is a JavaThread. It's getting yellow, red etc
> pages at the top. As these are 64K on 64K systems, the compiler
> thread stack has to be this big. Thus you actually need similar
> values once you run a linuxx86_64 VM on a system with 64K pages.
> Does this exist?

No idea, sorry.

> But, this means that there is no use of the OS guard pages
> configured in default_guard_size().  This is called with 'compiler_thread'
> for CompilerThreads.
>
> We should probably also return '0' in that case.
>
> What do you think?

I think I agree. As you note a CompilerThread is-a JavaThread even 
though the ThreadType enum treats them as completely distinct:

   enum ThreadType {
     vm_thread,
     cgc_thread,        // Concurrent GC thread
     pgc_thread,        // Parallel GC thread
     java_thread,
     compiler_thread,
     watcher_thread,
     os_thread
   };

so anything with VM supplied guard pages doesn't need the glibc ones as 
well.

I'm struggling to understand why os::Linux::default_guard_size is 
defined per CPU type? I would not expect this to need to vary based on 
CPU at all. ??

Thanks,
David

> Best regards,
>   Goetz.
>
> size_t os::Linux::default_guard_size(os::ThreadType thr_type) {
>   // Creating guard page is very expensive. Java thread has HotSpot
>   // guard page, only enable glibc guard page for non-Java threads.
>   return (thr_type == java_thread ? 0 : page_size());
> }
>