Hi,
If just doubling the size of the Reaper stack would suffice, I would
start there.
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.
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
