RFR: 8225035: Thread stack size issue caused by large TLS size

[David Holmes]

On 18/06/2019 8:41 am, Jiangli Zhou wrote:
> Hi Andrew and Florian,
> 
> With the stack size needs to be aligned at page boundary, it seems that 
> the effect of using large page size is the same for the following two 
> approaches:
> 
>  1. Using a JVM knob which specifies a minimum stack size for stack size
>     adjustment (suggested by Florian)
>  2. Using the value obtained from __pthread_get_minstack for stack size
>     adjustment 
> 
> The difference is that the second approach gets the adjustment value 
> without guessing, which seems to be more user friendly. What are your 
> thoughts on that? If there is anything that I'm missing, please correct.
> 
> After thinking more, it seems that the simple approach with an on/off 
> switch (suggested by David initially) that adjusts all threads' stack 
> size (for the on-stack TLS blocks) when the switch is enabled probably 
> is better. Any objections?

As long as it is off by default, no objections here.

Thanks,
David

> Thanks a lot for all the feedback and suggestions!!
> 
> Best regards,
> 
> Jiangli
> 
> On Mon, Jun 17, 2019 at 3:15 AM Andrew Haley <aph at redhat.com 
> <mailto:aph at redhat.com>> wrote:
> 
>     On 6/17/19 11:08 AM, Florian Weimer wrote:
>      >> I think I suggested before to have a JVM knob which specifies a
>     minimum
>      >> stack size for passing to libpthread.  This would be a rather
>      >> straightforward way to deal with applications which specify
>     impossibly
>      >> small thread stacks without having to recompile them.  If users
>      >> encounter a problem and they are on 64-bit architectures, they
>     can just
>      >> set that knob to 1 MiB because it's unlikely that they have to
>     conserve
>      >> address space.
>      >
>      > I still stand behind this suggestion.
> 
>     This is simple and has the considerable virtue of not needing any
>     particular
>     handling of large page sizes.
> 
>     -- 
>     Andrew Haley
>     Java Platform Lead Engineer
>     Red Hat UK Ltd. <https://www.redhat.com>
>     https://keybase.io/andrewhaley
>     EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>