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