Alright, we can abandon this change. In practice, tests on different platforms will usually catch SOE before users encounter it, because the stacks are all almost identical. Unless there is e.g. a hotspot bug that causes thread local variables to be allocated inside the stack size instead of outside.
Is there monitoring available that can warn when e.g. stack high-water mark is ever more than 50%? On Fri, Jul 18, 2014 at 7:40 AM, Rob McKenna <rob.mcke...@oracle.com> wrote: > 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 >>>> >>>> >>>> >
