RFC: 8139864: Improve handling of stack protection zones. (original) (raw)

Coleen Phillimore coleen.phillimore at oracle.com
Wed Oct 28 21:01:50 UTC 2015

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 DEFAULTSTACK*PAGES * defaultpagesize.

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

More information about the hotspot-runtime-dev mailing list