RFC: 8139864: Improve handling of stack protection zones.

[Coleen Phillimore]

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
>