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.ri...@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
