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

Florian Weimer fweimer at redhat.com
Thu Jun 27 09:09:06 UTC 2019


* 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.

In combination with the glibc stack setup code, __pthread_get_minstack
always accounts for the guard size.  In some glibc versions, the
accouting happens in the stack allocation, in other versions, in
__pthread_get_minstack.  But the net effect is that if you get the magic
number from __pthread_get_minstack, you do not need to add the guard
size anymore.  It's either in the __pthread_get_minstack value, or glibc
no longer considers the guard size as part of the guard size.  In both
cases, Hotspot should not add the guard size *again*.  At least not for
an option that says it's about TLS size.

Does this make sense?

Thanks,
Florian


More information about the hotspot-runtime-dev mailing list