On 15/01/2016 4:59 AM, Martin Buchholz wrote:
The process grim reaper ends up being the first point of failure since it tries not to waste the user's memory and it's in a core library, but in principle it's not special. I think a more general workaround would be to add a hotspot flag that would add a memory safety zone to all threads. If it's known that TLS is stealing 32k from every thread's stack, then the flag should ensure that every thread stack is 32k larger.
I think we need a point fix for the process reaper case in the immediate term. We can then consider how to better address the general case in the medium to long term.
More generally, I was hoping that hotspot would ensure that the -Xss size was available for actual java stack frames and OS overhead was added on automatically, but that is hard to implement, so the best alternative workaround is for users to be able to specify that additional stack size padding. Maybe -XX:StackSizeOverhead=32768 ?
Even this is still a band-aid - the user has to experience the problem, recognize it, and then figure out the right adjustment to add. Plus if any third-party library uses native TLS the requirement could change dynamically.
So I'd prefer a new RFE to look at this general issue. Thanks, David
