Re: Need help to understand TLS behavior

On Tue, Dec 15, 2015 at 9:40 PM, David Holmes wrote: > 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

Re: Need help to understand TLS behavior

On 16/12/15 05:35, David Holmes wrote: > It's kind of interesting we've never hit this before. It's very > frustrating that we hit it on a thread that couldn't care less about > the TLS variables that have claimed space on its stack. I guess they > need a notion of "inheritable thread-locals"

Re: Need help to understand TLS behavior

On Mon, Dec 14, 2015 at 8:44 PM, David Holmes wrote: > On 15/12/2015 6:53 AM, Martin Buchholz wrote: >> >> Thread local storage is trouble. >> >> java stack sizes should be in _addition_ to any OS overhead, which >> includes TLS. > > > TLS shouldn't be coming out the

Re: Need help to understand TLS behavior

Hi Jeremy, David, I would like to understand the problem better and have some questions, maybe you could answer? - What is the difference between "static __thread int x" and "__thread int x" - one lives in the thread stacks, one does not? - What happens with existing threads if a library is

Re: Need help to understand TLS behavior

On 15/12/2015 7:25 PM, Thomas Stüfe wrote: Hi Jeremy, David, I would like to understand the problem better and have some questions, maybe you could answer? The "specification" for ELF based TLS as I understood it is the Ulrich Drepper document I referenced: ""ELF Handling for Thread Local

Re: Need help to understand TLS behavior

On 16/12/2015 8:03 AM, Jeremy Manson wrote: On Mon, Dec 14, 2015 at 11:25 PM, David Holmes > wrote: On 15/12/2015 4:32 PM, Jeremy Manson wrote: David: What the spec says and what glibc does are two different

Re: Need help to understand TLS behavior

On 16/12/2015 6:23 AM, Martin Buchholz wrote: On Mon, Dec 14, 2015 at 8:44 PM, David Holmes wrote: On 15/12/2015 6:53 AM, Martin Buchholz wrote: Thread local storage is trouble. java stack sizes should be in _addition_ to any OS overhead, which includes TLS. TLS

Re: Need help to understand TLS behavior

On Mon, Dec 14, 2015 at 12:52 PM, Bernd Eckenfels wrote: > Maybe it can benefit from the new "No Inherit TLS" Thread constructor? If the process has TLS, then one has to assume there's a good reason, and it will be necessary.

Need help to understand TLS behavior

Hi, I am investigating an issue, in which test with TLS size set to 32K is failing with StackOverFlowError. During investigation I found the below code http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/tip/src/solaris/classes/java/lang/UNIXProcess.java ThreadFactory threadFactory = grimReaper

Need help to understand TLS behavior

Hi, I am investigating an issue, in which test with TLS size set to 32K is failing with StackOverFlowError. During investigation I found the below code /jdk8u-cpu /jdk /src

Re: Need help to understand TLS behavior

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. Jeremy On Mon, Dec 14, 2015 at 8:44 PM, David Holmes wrote: > On

Re: Need help to understand TLS behavior

On 15/12/2015 6:53 AM, Martin Buchholz wrote: Thread local storage is trouble. java stack sizes should be in _addition_ to any OS overhead, which includes TLS. TLS shouldn't be coming out the stack of the thread AFAIK - I see nothing about that in "ELF Handling for Thread Local Storage".

Re: Need help to understand TLS behavior

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

Re: Need help to understand TLS behavior

On 15/12/2015 6:52 AM, Bernd Eckenfels wrote: Am Mon, 14 Dec 2015 09:15:55 -0500 schrieb Roger Riggs : Hi, The reaper thread that waits for process exit has minimal stack requirements, and if possible should not consume all of the memory for a full stack. The 32k

Re: Need help to understand TLS behavior

Hi David, TLS is thread local storage. In test program it is defined using #define TLS_SIZE 32 int __thread XYZ[TLS_SIZE * 1024]; Regards, Cheleswer On 12/14/2015 6:29 PM, David Holmes wrote: What is TLS in this context? Thanks, David On 14/12/2015 10:34 PM, cheleswer sahu wrote: Hi, I am

Re: Need help to understand TLS behavior

Hi, The reaper thread that waits for process exit has minimal stack requirements, and if possible should not consume all of the memory for a full stack. The 32k number is a guess at a small stack. It has worked so far except in cases where the VM configuration or parameters increase the size

Re: Need help to understand TLS behavior

What is TLS in this context? Thanks, David On 14/12/2015 10:34 PM, cheleswer sahu wrote: Hi, I am investigating an issue, in which test with TLS size set to 32K is failing with StackOverFlowError. During investigation I found the below code

Re: Need help to understand TLS behavior

On 14/12/2015 11:06 PM, cheleswer sahu wrote: Hi David, TLS is thread local storage. In test program it is defined using #define TLS_SIZE 32 int __thread XYZ[TLS_SIZE * 1024]; Thanks for clarifying. What test is that? I'm guessing this may be a linux only test? Which platform do you see the

Re: Need help to understand TLS behavior

Thread local storage is trouble. java stack sizes should be in _addition_ to any OS overhead, which includes TLS. IOW, the java thread stack size should actually be available for stack frames. Hotspot should be fixed, but it's not easy. On Mon, Dec 14, 2015 at 12:47 PM, David Holmes

Re: Need help to understand TLS behavior

Am Mon, 14 Dec 2015 09:15:55 -0500 schrieb Roger Riggs : > Hi, > > The reaper thread that waits for process exit has minimal stack > requirements, > and if possible should not consume all of the memory for a full stack. > The 32k number is a guess at a small stack. It