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

[Thomas Stüfe]

Hi Florian,

On Thu, Jun 27, 2019 at 9:57 AM Florian Weimer <fweimer at redhat.com> wrote:

> * Thomas Stüfe:
>
> >> I think
> >>
> >>   stack_adjust_size += guard_size;
> >>
> >> is redundant with the get_minstack-based adjustment because it is either
> >> included in it directly in the get_minstack value, or indirectly in the
> >> updated stack size computation in glibc (where it adds the guard size
> >> internally).
> >
> > Please do not change this!
> >
> > To me and I guess many others it is very important that nothing at all
> > changes if this workaround is off.
>
> That has already happened because recent glibc adds the guard size to
> the stack size internally now.


But what I meant: only perform the += adjustment above for the
> !AdjustStackSizeForTLS case.
>

Yes, this is what I meant with "I'd like to keep this coding simple". The
switch supposedly has only to do with TLS, so for the casual code reviewer
it makes no sense to bring guard page size into this.

I do not try to be obtuse here :) I just have pity with myself in some
years when I may still have to understand this coding.


> >> I suspect this new flag is is working well because it effectively
> >> adds 20 KiB to all requested stack sizes (page size plus
> >> PTHREAD_MIN_STACK).  The static TLS size adjustment may not matter
> >> at all.  On older glibcs, the number is even higher because your
> >> code adds the guard size twice (once in __pthread_get_minstack, once
> >> in the Hotspot code).
> >
> > Which, again, would be an argument for a much simpler
> > "-XX:MinStackSize" option...
>
> Indeed.
>
>
BTW your prior points were good. If we go with pthread_get_minstack(), the
workaround should not add much size to thread stacks if TLS areas are
small. In other words, TLS size should matter. Otherwise we may just add a
fixed amount to the stack size...


> Thanks,
> Florian
>

Cheers, Thomas