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
