8050044: (process) Increase reaper thread native stack size by a factor of 2

[Rob McKenna]

So doing a bit of homework should probably have been my first approach.

Interestingly, we are never actually going to have only 32k allocated 
for the stack. The VM will allocate the 
os::Solaris|Linux|etc::min_stack_allowed size which is a minimum of 48k 
on some platforms but generally 64k+. Windows goes to the trouble of 
calculating the value based on the guard pages and some other variables.

In effect, with the 32k value we're asking the (more specifically, our) 
VM to allocate the minimum possible stack which is calculated on a 
per-platform basis. Perhaps the "fix" for this bug should really just be 
a comment acknowledging that this is a minimum acceptable value and the 
VM will likely determine the actual size?

     -Rob

On 15/07/14 18:58, Martin Buchholz wrote:
> The fear is that stack sizes and alignments have grown over time, and
> thread stacks are acquiring things like guard pages, and those pages may
> (incorrectly) end up getting included in the stack size.  I'm particularly
> afraid of the hotspot guard page code.
>
> It may be worthwhile seeing how low you can make the stack size on popular
> platforms before the jtreg tests for process fall over, then multiply by 10
> at least.
>
> We are approaching the 64-bit only era, when address space restrictions
> won't be a problem (for a while)
>
>
> On Tue, Jul 15, 2014 at 10:51 AM, roger riggs <roger.riggs at oracle.com>
> wrote:
>
>> Hi Rob,
>>
>> Is there any evidence that needs more space?  Is there any way to tell how
>> much of
>> the existing 32k is being used?
>> The reaper has very limited processing to do and there is one thread for
>> every process spawned.
>>
>> Roger
>>
>>
>>
>> On 7/15/2014 1:46 PM, Rob McKenna wrote:
>>
>>> Hi folks,
>>>
>>> A very simple change suggested by Martin a while back in another review.
>>> I'm just getting around to it now:
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8050044
>>> webrev: http://cr.openjdk.java.net/~robm/8050044/webrev.01/
>>>
>>> Martins comments: http://mail.openjdk.java.net/
>>> pipermail/core-libs-dev/2014-March/025943.html
>>>
>>>      -Rob
>>>
>>>