Need help to understand TLS behavior

[David Holmes]

On 16/12/2015 8:03 AM, Jeremy Manson wrote:
>
>
> On Mon, Dec 14, 2015 at 11:25 PM, David Holmes <david.holmes at oracle.com
> <mailto:david.holmes at oracle.com>> wrote:
>
>     On 15/12/2015 4:32 PM, Jeremy Manson wrote:
>
>         David: What the spec says and what glibc does are two different
>         things:
>
>         https://sourceware.org/bugzilla/show_bug.cgi?id=11787
>
>         We have an internal Google patch to compensate for this.  Nasty
>         stuff.
>
>
>     Nasty isn't even the right word - this is just ludicrous! And the
>     bug has just languished even though they were going to fix it years
>     ago!!!!! And I also cried when I saw the part finally recognizing
>     that glibc does the wrong thing by taking the guard pages from the
>     requested stack size!
>
>     To me this just screams don't use TLS on linux except for trivially
>     small data structures, or else use static-TLS.
>
>     Which brings me back to this test - make the variable static!
>
>     Thanks Jeremy. I'm thoroughly depressed now.
>
>
> Happy to oblige.  :)
>
> The really depressing part is that there is no standard way of figuring
> out how much TLS you need so that you can compensate.  Note that the
> Rust people are trying to introspect into glibc to figure it out.  We
> roll our own glibc, so at least we can export something that we
> guarantee can work.  You would probably want to avoid both of these
> situations for the JDK.

Definitely do not want to roll our own glibc :) The Rust approach is 
unappealing but perhaps doable - I'm not sure what impact it would have 
with regard to build-time versus run-time dependencies.

> I expect the official answer from you guys about this is going to end up
> being "bump your Xss if you really care", which is deeply sad.

As a point fix a way to change the stack size of the process reaper 
thread might suffice. But that is a band-aid. I can imagine bugs of the 
form "when we run our Java code stand-alone it runs fine, but as soon as 
we embed the JVM in our own application front-end it fails with 
StackOverflowErrors everywhere". :(

David

> Jeremy