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
