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

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