Need help to understand TLS behavior
Jeremy Manson
jeremymanson at google.com
Tue Dec 15 06:32:39 UTC 2015
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.holmes at 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.holmes at 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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
More information about the core-libs-dev
mailing list