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 loaded which uses this form of TLS? - Does this TLS live at the top of the stack? So, to find out if a third party library uses this form of TLS, we could check the distance of sp to the stack base in java_start()? - Would the region returned by pthread_attr_getstack() include the TLS region? Thanks! Kind Regards, Thomas On Tue, Dec 15, 2015 at 8:25 AM, David Holmes <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. > > David > ----- > > Jeremy >> >> On Mon, Dec 14, 2015 at 8:44 PM, David Holmes <david.hol...@oracle.com >> <mailto:david.hol...@oracle.com>> 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 stack of the thread AFAIK - I see >> nothing about that in "ELF Handling for Thread Local Storage". That >> is why I want to know more about the test, the compilation >> environment and the execution environment. >> >> IOW, the java thread stack size should actually be available for >> stack frames. >> Hotspot should be fixed, but it's not easy. >> >> >> Do you mean that the value specified at the Java level should be >> rounded up to accommodate guard pages etc at the native level? >> >> David >> ----- >> >> >> On Mon, Dec 14, 2015 at 12:47 PM, David Holmes >> <david.hol...@oracle.com <mailto:david.hol...@oracle.com>> wrote: >> >> 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 problem on? >> >> We don't unconditionally use compiler-based TLS as some >> platforms may not >> support it. >> >> That aside that declaration should really be static I think. >> >> David >> ----- >> >> >> 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 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 -> { >> // Our thread stack >> requirement is quite modest. >> Thread t = new >> Thread(systemThreadGroup, grimReaper, >> >> "process reaper", 32768); >> >> Here reaper thread is created with fixed stack >> size "32768 ", which >> causes StackOverFlowError when TLS is set to >> 32k around. >> If I remove this fixed size and make it default, >> test works fine. >> >> Thread t = new Thread(systemThreadGroup, >> grimReaper, >> >> "process reaper"); >> >> I have run several test with TLS size 32k , 64k >> ,128k and more . >> The interesting part, it works well with 64k and >> 128k TLS size but not >> with 32k. >> So my questions are as follows: >> >> >> What is the motivation behind the fixed >> thread stack size ? >> will it be ok to replace the fixed stack >> size with default or stack >> >> >> size setting is platform sensitive? >> >> >> How TLS sizes are interpreted internally, >> which allows 64k and 128k >> >> >> to work but not to 32k ? >> >> I would really appreciate, if anyone have any >> opinion on this. >> >> Regards, >> Cheleswer >> >> >> >> >> >> >>
