RFR (XXS): 8079156: 32 bit Java 9-fastdebug hit assertion in client mode with StackShadowPages flag value from 32 to 50

[Coleen Phillimore]

It would be nice to get an opinion from the compiler group.  The 
deopt_blob had this stack banging as some sort of assertion check that 
the underlying compiled code already had the stack banging. I'm not sure 
how helpful it is if it crashes here in finding any problems, because 
I'm not sure how well stack walking for implicit exceptions works 
through a deopt blob.  My thought is that the code never expects an 
implicit exception in a deopt blob so wouldn't work very well.

If this is the case, Gerald could simply remove this code from deopt 
blob, avoiding the sizing issue entirely.

Thanks,
Coleen


On 7/13/15 10:17 AM, gerard ziemski wrote:
> hi David,
>
> On 07/13/2015 12:34 AM, David Holmes wrote:
>> Hi Gerard,
>>
>> On 11/07/2015 7:09 AM, gerard ziemski wrote:
>>> (resending - forgot to include the issue number in the title)
>>>
>>> Hi all,
>>>
>>> Please review this very small fix:
>>>
>>>     bug: https://bugs.openjdk.java.net/browse/JDK-8079156
>>> webrev: http://cr.openjdk.java.net/~gziemski/8079156_rev0
>>
>> I'd like to hear from the compiler folk about this bug as I'm unclear 
>> on why StackBanging adds to the code buffer, and why this suddenly 
>> seems to be a new problem - did something change? Or have we not 
>> exercised the range of values before?
>
> My best educated quess is that the issue was always in there, but we 
> never exercised that path - Dmity's only added his testing framework 
> for exercising the ranges after we got the range/constraints check 
> feature in recently and that's when we found it.
>
>
>>
>> I'd also like to understand whether the code buffer resizing should 
>> be rounded up (or whether it will be rounded up internally)? e.g. 
>> power of two, multiple of nK for some n etc.
>
> I checked the sizes of existing CodeBuffers instr sizes and some 
> values I saw are: 416,536,544,560,568, so I'm not sure what the 
> constraint here is if there really is one (other than divisible by 4, 
> which 112 is as well)
>
>
>>
>> The 112 value seems odd for 50 pages - is this 2 bytes (words?) per 
>> page plus some fixed overhead? Can it be expressed as a function of 
>> StackShadowPages rather than hardwiring to 112 which only works for 
>> values < 50?
>
> Hardcoding the value for 50 pages should be OK here since that's the 
> max value that StackShadowPages can take.
>
> Expressing it as some function would not be all that simple - you 
> would need to take in account that the default size is enough for some 
> StackShadowPages (ie.32), then find out the fixed size for the stack 
> banging function. In the end you would end up with some hardcoded 
> values anyhow, so why not make it super simple as we did here?
>
> The other way is to calculate things dynamically and I actually did 
> that: my first fix was based on creating a temp CodeBuffer and feeding 
> it only shadow stack banging code to find out the exact size 
> requirement for that code, but I was told that this might confuse some 
> compiler code later that wouldn't expect it. The other unknown was 
> whether the temp code buffer code actually made it into in the cache 
> (is it flushed by the destructor?). I tried to find a way to wipe out 
> the instr section before the destructor, but couldn't find any APIs 
> for doing so.
>
> I don't know the answers to those issues, so even though I liked the 
> idea of using a temp buffer to find out precisely how much more memory 
> we used, in the end I settled on the simplest solution that works.
>
> Would folks from the compiler like to comment?
>
>
> cheers
>