[prev in list] [next in list] [prev in thread] [next in thread]
List: openjdk-hotspot-runtime-dev
Subject: RE: RFC: 8139864: Improve handling of stack protection zones.
From: "Lindenmaier, Goetz" <goetz.lindenmaier () sap ! com>
Date: 2015-10-29 9:37:06
Message-ID: 4295855A5C1DE049A61835A1887419CC41EACEC3 () DEWDFEMB12A ! global ! corp ! sap
[Download RAW message or body]
Hi Coleen, Dean,
Yes, I can make the change if there is an agreement how to handle it.
> setting 1 may cause customers to get stack overflow SEGVs with normal page sizes \
> but so would setting a higher value (like 3).
If we use a fixed lower bound, we really should use 1.
Using 3 would mean on 64K systems (3+1+1)*64K = 320K of protected area. What a waste!
> People have suggested adding these parameters, but they seem like more work for us. \
>
What kind of work do you think of? Implementing the new flags, or finding new \
settings for already configured applications? For us, the second is an issue, but we \
still would appreciate a more portable set of flags.
> Plus rounding to page size, you might as well specify the value in pages.
The problem is that page size differs from system to system.
* This is not user friendly, as users need to know the page size of their system.
* The size of the shadow area depends on frame sizes. These do not vary
from system to system (only from platform to platform).
* Other stack sizes are given in Kbytes. One combination of flags does result
in very different usable stack sizes for the application, at least if you look \
at the current documentation of the flags (see below).
An example:
ThreadStackSize=512K, Red=1, Yellow=2, Shadow=5
4Kpages: 512K - 32K = 480K usable space -- application runs well
16Kpages: 512K - 128K = 384K usable space -- application gets stack overflow
64Kpages: 512K - 512K = 0K usable space -- application does not start at all \
This is partially fixed in os coding by adapting the number of red/yellow/shadow
pages. But that is not documented in the flags.
This issue can not be overcome completely, as one page is needed at least.
* Other stack sizes are also rounded to page sizes, e.g., see os_linux.cpp:4732
I think it's a good idea to fix the Red/Yellow/Shadow flags to 4K as Dean
proposes. This makes it portable, easy to document and avoids new flags.
In effect, it will halve the protected sizes on systems that have pages > 4K,
as currently the sizes are adapted (# pages reduced) on base of 8K page size.
Further, this effect is reduced by page rounding.
Also, it will give applications on systems with >4K who don't set these flags
more usable space on the stack without increasing the risk of unrecoverable
stack overflow in comparison to the 4K system.
Best regards,
Goetz.
/* stack parameters */ \
product_pd(intx, StackYellowPages, \
"Number of yellow zone (recoverable overflows) pages") \
range(MIN_STACK_YELLOW_PAGES, (DEFAULT_STACK_YELLOW_PAGES+5)) \
\
product_pd(intx, StackRedPages, \
"Number of red zone (unrecoverable overflows) pages") \
range(MIN_STACK_RED_PAGES, (DEFAULT_STACK_RED_PAGES+2)) \
\
/* greater stack shadow pages can't generate instruction to bang stack */ \
product_pd(intx, StackShadowPages, \
"Number of shadow zone (for overflow checking) pages " \
"this should exceed the depth of the VM and native call stack") \
range(MIN_STACK_SHADOW_PAGES, (DEFAULT_STACK_SHADOW_PAGES+30)) \
\
\
product_pd(intx, ThreadStackSize, \
"Thread Stack Size (in Kbytes)") \
range(0, max_intx-os::vm_page_size()) \
\
product_pd(intx, VMThreadStackSize, \
"Non-Java Thread Stack Size (in Kbytes)") \
range(0, max_intx/(1 * K)) \
\
product_pd(intx, CompilerThreadStackSize, \
"Compiler Thread Stack Size (in Kbytes)") \
range(0, max_intx)
From: Coleen Phillimore [mailto:coleen.phillimore@oracle.com]
Sent: Mittwoch, 28. Oktober 2015 22:02
To: Lindenmaier, Goetz; Gerard Ziemski (gerard.ziemski@oracle.com); \
hotspot-runtime-dev@openjdk.java.net
Subject: Re: RFC: 8139864: Improve handling of stack protection zones.
On 10/19/15 3:35 AM, Lindenmaier, Goetz wrote:
Hi,
I opened this issue because I think the lower bounds for StackRedPages,
StackYellowPages and StackShadowPages introduced in 8078556 cause
problems on systems with page sizes > 8K.
For a more detailed description of the problems to expect see
https://bugs.openjdk.java.net/browse/JDK-8139864.
I see a row of possible solutions to this.
1.) Just set the lower bounds to '1'. That's what I proposed before.
I can imagine setups where one wants to reduce the size of these zones to a \
minimum. If an application starts a lot of threads, and is known not to overflow \
stacks, this might be desirable to save memory.
Yes, I think 1 would be an acceptable minimum. It doesn't matter for yellow and red \
pages, but for shadow pages, setting 1 may cause customers to get stack overflow \
SEGVs with normal page sizes but so would setting a higher value (like 3). There \
really isn't a good minimum so I think 1 might be something a customer might want to \
set so we shouldn't disallow it.
2.) Implement constraint methods that assure the zones never get smaller than \
DEFAULT_STACK_*_PAGES * default_page_size. This is necessary if you want to make \
sure the zones never can get smaller than that.
3.) Introduce new flags StackRedZoneSize, StackYellowZoneSize and \
StackShadowZoneSize. Set the default values to those of StackRedPages *4K etc, which \
is the most common page size I guess. During startup, round these to page size.
Use Stack*ZoneSize in the code.
If Stack*Pages flags are set on the command line, convert them to Stack*ZoneSize \
by multiplying with the current page size.
People have suggested adding these parameters, but they seem like more work for us. \
Plus rounding to page size, you might as well specify the value in pages. And \
adding parameters gives us more things to test and maintain.
Were you going to make this change?
Thanks,
Coleen
I'm happy to make a webrev for the favored solution.
Best regards,
Goetz
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic