Need help to understand TLS behavior

David Holmes david.holmes at oracle.com
Mon Dec 14 20:47:54 UTC 2015


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



More information about the core-libs-dev mailing list