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

Martin Buchholz martinrb at google.com
Tue Jul 15 17:58:22 UTC 2014

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>

> 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

More information about the core-libs-dev mailing list