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 <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> >> 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 >>>>>> >>>>>> >>>>>> >>>>>> >>>> >>>
