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

[gerard ziemski]

I believe this to be an opportunity to make the CodeBuffer more robust 
with the possible advantage of actually saving memory - assuming it can 
automatically grown/shrink as needed. I have filed JDK-8131167 as a 
follow-up to this issue to give ourselves a chance to think about this more.


cheers

On 07/14/2015 11:02 AM, Vladimir Kozlov wrote:
> You are right but we don't want spent too much time on this. Code will 
> become more complex than current. And since with grow() we usually 
> double size we may consume more memory than with current guess.
>
> Vladimir
>
> On 7/14/15 8:00 AM, gerard ziemski wrote:
>>
>> On 07/13/2015 07:42 PM, Vladimir Kozlov wrote:
>>> On David's question. The size of code is rounded to 64 bytes 
>>> (minimum allocation unit in CodeCache). So you don't need
>>> to rounding.
>>>
>>> We do calculate additional padding on sparc taking into account 
>>> instructions sizes and number of StackShadowPages
>>> pages (which banging code is looping on):
>>>
>>> #ifdef ASSERT
>>>   if (UseStackBanging) {
>>>     pad += StackShadowPages*16 + 32;
>>>   }
>>> #endif
>>>
>>> But on x86 we have variable instructions size so it is not easy 
>>> pre-calculate it.
>>> So we simple set big number and if we hit the assert in 
>>> codeBuffer.hpp we increase it:
>>
>> It sounds like we had to do this before.
>>
>> Why does CodeBuffer require the space requirements in advance? 
>> Wouldn't it be more robust to leave it up to the
>> CodeBuffer to figure out the exact memory size needed and avoid 
>> situations like this? It seems fragile to have to guess
>> how big we need it and hope we don't hit the assert with all the 
>> bells and whistles turned on.
>>
>>
>> cheers
>
>