8050044: (process) Increase reaper thread native stack size by a factor of 2 (original) (raw)
Martin Buchholz martinrb at google.com
Tue Jul 15 17:58:22 UTC 2014
- Previous message: RFR: 8050044: (process) Increase reaper thread native stack size by a factor of 2
- Next message: 8050044: (process) Increase reaper thread native stack size by a factor of 2
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: RFR: 8050044: (process) Increase reaper thread native stack size by a factor of 2
- Next message: 8050044: (process) Increase reaper thread native stack size by a factor of 2
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]