On 16/12/2015 8:03 AM, Jeremy Manson wrote:
On Mon, Dec 14, 2015 at 11:25 PM, David Holmes <david.hol...@oracle.com <mailto:david.hol...@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
