Take 2: RFR: 8197429: Increased stack guard causes segfaults on x86-32

[David Holmes]

Hi Andrew,

On 14/02/2018 10:55 PM, Andrew Haley wrote:
> On 14/02/18 02:10, David Holmes wrote:
>> On 14/02/2018 12:51 AM, Andrew Haley wrote:
>>> Webrev amended.
>>>
>>> http://cr.openjdk.java.net/~aph/8197429-2/
>>
>> My question still stands:
> 
> Sorry, I didn't see it.
> 
>> How does this interact with the use of DisablePrimordialThreadGuardPages?
> 
> My initial answer was "not at all", but there is a minor possible
> modification.  If DisablePrimordialThreadGuardPages is set it is
> possible to use slightly more stack in Java code, so we could bang
> down slightly further in workaround_expand_exec_shield_cs_limit() and
> therefore place the codebuf slightly lower.  This would allow every
> page of the primordial stack to be used in Java code.
> 
> Like this:
> 
>    if (os::is_primordial_thread()) {
>      address limit = Linux::initial_thread_stack_bottom();
>      if (! DisablePrimordialThreadGuardPages) {
>        limit += JavaThread::stack_red_zone_size() +
>          JavaThread::stack_yellow_zone_size();
>      }
>      os::Linux::expand_stack_to(limit);
>    }
> 
> I'm happy to make that change and add a test for
> DisablePrimordialThreadGuardPages if you think it's worth doing.
> 
> Alternatively, we could simply ignore the JVM's stack guard pages in
> the calculation and always bang down all the way to
> initial_thread_stack_bottom().  This would cause the codebuf to be
> mapped slightly lower, but I guess that's no big deal.

My main concern was to ensure that this did not somehow cause 
DisablePrimordialThreadGuardPages to break. IIUC without the suggested 
adjustment this change would slightly reduce the amount of stack 
available for use - in which case I'd prefer to see the adjustment made 
in either form you deem best.

Thanks,
David