RFR(XS): 8024128: guarantee(codelet_size > 0 && (size_t)codelet_size > 2*K) failed: not enough space for interpreter generation

[Leslie Zhai]

Hi Volker,

Thanks for your patch! 
http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-August/028162.html

I am backporting to jdk8u-dev now :) 
https://raw.githubusercontent.com/xiangzhai/jdk8u-dev/master/JDK-8166317-Backport.patch


在 2018年09月15日 10:51, Leslie Zhai 写道:
> Hi Vladimir,
>
> Thanks for your kind response!
>
> It is Server VM, I am just debugging HotSpot C2.  Yes, I changed 
> ReservedCodeCacheSize to 3m.
>
> It is able to reproduce by jtreg for jdk8u fastdebug when 
> InterpreterCodeSize is too big, for example 640K:
>
> $ jtreg -dir:/home/xiangzhai/project/jdk8u/hotspot/test -verbose:all 
> -a -ignore:quiet -timeoutFactor:5 -agentvm 
> -testjdk:/home/xiangzhai/project/jdk8u/build/linux-x86_64-normal-server-fastdebug/images/j2sdk-image 
> compiler/startup/SmallCodeCacheStartup.java
>
> Native memory allocation (malloc) failed to allocate 2621440 bytes for 
> CodeCache: no room for Interpreter
>
> It is clear that failed to allocate BufferBlob -> CodeBlob.
>
> And it is also able to reproduce for release when too small, for 
> example 200K, but *no* changing ReservedCodeCacheSize:
>
> $ jtreg -dir:/home/xiangzhai/project/jdk8u/jdk/test -verbose:all 
> -exclude:/home/xiangzhai/project/jdk8u/jdk/test/ProblemList.txt 
> -conc:2 -Xmx512m -a -ignore:quiet -timeoutFactor:5 -agentvm 
> -testjdk:/home/xiangzhai/project/jdk8u/build/linux-x86_64-normal-server-release/images/j2sdk-image 
> com/sun/jdi/AccessSpecifierTest.java
>
> It is sensible that codelet_size = 
> AbstractInterpreter::code()->available_space() - 2*K  is too small.
>
> And CodeBuffer might failed to verify the allocation for each section 
> due to guarantee(sect->end() <= tend, "sanity");
>
> So for X86 the suitable range of InterpreterCodeSize might be [250K, 
> 600K], but for AArch64 is 200K[1].  What is the root cause behind it?  
> It is just like magic number by running with +PrintInterpreter to get 
> the VM to print out the size.  I need to dig deep-in to find the root 
> cause.
>
> [1] 
> http://hg.openjdk.java.net/aarch64-port/jdk8u/hotspot/file/6bc3e4922a8b/src/cpu/aarch64/vm/templateInterpreter_aarch64.hpp#l38
>
>
> 在 2018年09月15日 02:33, Vladimir Kozlov 写道:
>> Hi Leslie
>>
>> More context is needed. Is it Client or Server VM? Did you change 
>> ReservedCodeCacheSize?
>> Even with *4 it is about 1Mb when CodeCache size is 48Mb and in 
>> Tiered case even bigger.
>> Also we need call stack when you hit guarantee().
>>
>> Regards,
>> Vladimir
>>
>> On 9/14/18 4:31 AM, Leslie Zhai wrote:
>>> Hi,
>>>
>>> I just quoted the old thread 
>>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2013-October/012243.html
>>>
>>> I think we should increase it more for future otherwise you will 
>>> have to
>>> always catch up with interpreter changes.
>>>
>>> Increase it to 256 * 1024 and 224 * 1024
>>>
>>> Vladimir
>>>
>>> On 10/16/13 12:22 PM, Albert Noll wrote:
>>>  > Hi,
>>>  >
>>>  > could I have a review for this patch?
>>>  >
>>>  > bug: https://bugs.openjdk.java.net/browse/JDK-8026708
>>>  > webrev: http://cr.openjdk.java.net/~anoll/8026708/webrev.00/
>>>  > <http://cr.openjdk.java.net/%7Eanoll/8026708/webrev.00/>
>>>  >
>>>  > Problem: Not enough room for interpreter. My last patch did not 
>>> solve
>>>  > the problem for solaris-amd64.
>>>  >                 A local build (solaris-amd64) of the most recent
>>>  > hotspot-comp version requires a template interpreter
>>>  >                 size of 211K (obtained with -XX:+PrintInterpreter).
>>>  > There have been some modifications to the template
>>>  >                 interpreter in the last couple of weeks which 
>>> might have
>>>  > triggered this error.
>>>  >
>>>  > Solution: Increase interpreter size by 8k (32-bit and 64-bit).
>>>  >
>>>  > Testing: Failing test case in solaris-amd64
>>>
>>> ----- 8< -------- 8< -------- 8< -------- 8< -------- 8< -------- 8< 
>>> ---
>>>
>>> I found that `InterpreterCodeSize` had been changed from 200K to 
>>> 208K [1] ,  then changed from 208K to 256K [2] by Albert. But if 
>>> built with-debug-level=fastdebug/slowdebug,  it will be multiplied 
>>> by four:
>>>
>>> NOT_PRODUCT(code_size *= 4;)  // debug uses extra interpreter code 
>>> space
>>>
>>> Then it might trigger Native memory allocation (malloc) failed to 
>>> allocate xxx bytes for CodeCache: no room for Interpreter issue.
>>>
>>> I don't want to always catch up with interpreter changes by guessing 
>>> the suitable number, not too small, not too big :) Please give me 
>>> some suggestion about the root cause,  thanks a lot!
>>>
>>> Leslie Zhai
>>>
>>> [1] http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/6d7eba360ba4
>>>
>>> [2] http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/74e00b98d5dd
>>>
>>>
>

-- 
Regards,
Leslie Zhai