RFR[9u-dev] 8130425: libjvm crash due to stack overflow in executables with 32k tbss/tdata

[David Holmes]

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