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

[Thomas Stüfe]

Hi Jiangli+Florian+David,

I have some questions about this issue. I read through the mail thread, the
CSR and the associated glibc issue. Sorry if the questions have been
answered already :)

What I do not understand is:  TLS seems to be dynamic memory in the sense
that calling pthread_key_create will increase the footprint to be paid
(otherwise we would see these problems always, not just with e.g. jemalloc,
yes?), so how does adding a static size(is it?) to the stack help with that?

Also, how does that work: when I create a thread and it calls
pthread_key_create() a million times (is there an upper limit?), I guess
now I need space for a million TLS slots in all threads, not just the one
calling pthread_key_create()? So future threads will be started with less
real stack space available? And how does that work with already living
threads, does their TLS region in the stack get somehow expanded? If yes,
how? Does the TLS live at the end of the stack?

So much confusion :)

Thanks! ..Thomas

On Tue, Jun 11, 2019 at 12:30 AM Jiangli Zhou <jianglizhou at google.com>
wrote:

> Hi David and Florian,
>
> This the a follow up of the discussion regarding the TLS (Thread Local
> Storage) issue:
>
> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2019-May/034459.html
> .
> The following is an updated patch with your suggestions incorporated:
>
> 1) Use __pthread_get_minstack
> 2) By default only adjust the thread stack size if the
> minstack-to-stacksize ratio is >= 10%
> 3) Introduce a new command-line option (Linux only),
> AdjustWithMinStackAt, which can be used to change the default 10%
> ratio for triggering stack size adjustment
>
> CSR: https://bugs.openjdk.java.net/browse/JDK-8225498
> webrev: http://cr.openjdk.java.net/~jiangli/8225035/webrev.00/
> bug: https://bugs.openjdk.java.net/browse/JDK-8225035
>
> Best regards,
>
> Jiangli
>