The `glibc` library allocates some thread-local storage (TLS) in the stack of a newly created thread, leaving less stack than requested for the thread to do its work. This is particularly a problem for threads with small stack sizes. It is an inherited issue from a well-known `glibc` problem, 'Program with large TLS segments fail' [0] and has been observed in Java applications. In one of the reported JVM failure instances, the issue manifests as a `StackOverflowError` on the process reaper thread, which has a small stack size. The `java.lang.Thread` constructor enables users to specify the stack size for a new thread. The created thread may encounter the TLS problem when the specified size is too small to accommodate the on-stack TLS blocks.

In JDK 8, a system property, `jdk.lang.processReaperUseDefaultStackSize`, was introduced to address the TLS issue only for reaper threads. Setting the property gives a bigger stack size to the reaper threads.

To address the issue for all threads, a general purpose workaround was implemented in Java which adjusts thread stack size for TLS. It can be enabled by using the `AdjustStackSizeForTLS` command-line option:

` -XX:+AdjustStackSizeForTLS`

When creating a new thread, if `AdjustStackSizeForTLS` is true, the static TLS area size is added to the user requested stack size. `AdjustStackSizeForTLS` is disabled by default.

Reference:
[0] [Bug 11787 - Program with large TLS segments fail](https://sourceware.org/bugzilla/show_bug.cgi?id=11787)