RFR (XXS): 8079156: 32 bit Java 9-fastdebug hit assertion in client mode with StackShadowPages flag value from 32 to 50
gerard.ziemski at oracle.com
Mon Jul 13 14:17:01 UTC 2015
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?
More information about the hotspot-compiler-dev