RFR[9u-dev] 8130425: libjvm crash due to stack overflow in executables with 32k tbss/tdata
david.holmes at oracle.com
Fri Jan 15 02:32:22 UTC 2016
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
So I'd prefer a new RFE to look at this general issue.
More information about the hotspot-runtime-dev