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

[gerard ziemski]

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