RFR: 8225035: Thread stack size issue caused by large TLS size
Florian Weimer
fweimer at redhat.com
Fri Jun 14 17:14:42 UTC 2019
* Thomas Stüfe:
> I am currently trying to find out the answer to my original question:
> what - in this figure
> (https://docs.oracle.com/cd/E19253-01/817-1984/6mhm7plaa/index.html#chapter8-fig-1
> - I assume that is the correct one for x64?) - is located on the
> thread stack, and where.
I think this picture is misleading as far as the issue is concerned.
On startup, the size of the static TLS area is determined once and for
all and stored in GL(dl_tls_static_size). Strictly speaking, only
initial-exec TLS needs to be allocated in the static TLS area, but at
present, the area is larger than what is absolutely required: there is a
reserve, and *all* TLS memory of any kind is put into the static TLS
area, including global-dynamic TLS from the initially loaded shared
objects.
In the current implementation, the TCB and the static TLS area are part
of the stack for each thread. In essence, what happens is this
(REAL_STARTUP and CLOSURE are the arguments to the pthread_create
function):
void *
startup_routine_wrapper (void (*real_startup) (void *), void *closure)
{
struct
{
struct tcb tcb;
char tls_area[GL(dl_tls_static_size)] __align(GL(dl_tls_static_align));
} thread_area;
/* Change the thread pointer to point to &thread_area.tcb or somewhere
around it; details are very architecture-specific. */
...
void *result = real_startup (closure)
/* Perform cleanup etc., and then store result somewhere. */
...
}
So conceptually, the user-supplied thread startup routine runs with the
TLS variables on the stack. The actual implementation is much different
because the TCB is put on the stack before calling the startup routine,
and the wrapper we have doesn't set up the TCB.
>From someone wrapping the pthread stack size controls, it doesn't really
matter how GL(dl_tls_static_size) is computed. The problem is that it
is there, eats into the user-specified stack size, and is impossible to
know statically.
Does this explanation help?
Thanks,
Florian
More information about the hotspot-runtime-dev
mailing list