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

[David Holmes]

Hi Roger,

On 16/01/2016 3:43 AM, Roger Riggs wrote:
> Hi,
>
> If just doubling the size of the Reaper stack would suffice, I would
> start there.

That's too specific. It might be fix this problem case today, but break 
again tomorrow.

> If a mechanism (property) is needed to make an adjustment to the stack
> size,
> then I'd prefer something that applied to all Threads, not just the reaper.

We already have means of changing other threads (eg -Xss for Java 
threads) the problem here is that the process reaper thread stack size 
is hard-wired. So we need some way to say control that.

David
-----

> It can be done in the Java code in Thread and would be low overhead and not
> so a specialized bit of code that needs to be maintained and documented
> for a single code path.
>
> We have seen other cases where the minimum stack size is not sufficient
> when executing with various VM switch combinations.
> Having an adjustment would address those to.
>
> $.02, Roger
>
>
>
> On 1/14/16 9:32 PM, David Holmes wrote:
>> 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
>