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

Lindenmaier, Goetz goetz.lindenmaier at sap.com
Wed Nov 25 15:55:19 UTC 2015

Hi,

For a description of the problem see https://bugs.openjdk.java.net/browse/JDK-8139864

This is a first version of my implementation of the proposal '3' that was discussed here: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-October/016085.html which is continued here http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-November/016805.html

Opposed to my original proposal, I did not introduce new flags. I documented the old flags to specify 4K pages, and save the ergonomic values in static fields of JavaThread. This avoids two sets of similar flags.

To simplify reviewing, I made two webrevs for the first round: The basic changes to determining the sizes of the zones to protect are in this partial webrev: http://cr.openjdk.java.net/~goetz/webrevs/8139864-StackZones/webrev.00-basic/ This contains the functional change.

If we agree on this, I need to replace all occurrences of the three flags by accessor calls. This allows to simplify all the platform code which computed the space required over and over again: http://cr.openjdk.java.net/~goetz/webrevs/8139864-StackZones/webrev.00-spread/

Actually I think there is no need that the shadow zone is page aligned. There are no pages to allocate or protect. The size of this zone is only used for banging. In most places only the upper bound of the zone is banged. In few places, all pages within this zone are banged. But this code also does not depend on a page aligned size. Removing the rounding to page sizes here could free up stack space for real usage. But I think that should be done in an extra change.

I also fixed the bounds of ThreadStackSize and CompilerThreadStackSize which allowed to specify stacks >> max_intx.

If this is agreed on, I will check for jtreg tests that fail on systems with stack pages > 4K and add the fixes to this change.

Best regards, Goetz.

More information about the hotspot-runtime-dev mailing list