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

[Leslie Zhai]

Hi Erik,

Thanks for your refactory of interpreter GC barriers! 
https://bugs.openjdk.java.net/browse/JDK-8199417


在 2018年09月15日 23:35, 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
When I am trying to implement `g1_barrier_stubs_init` for X86 and other 
Targets, I found that you refactoried `gc_barrier_stubs_init`, I need to 
read carefully about your patch.  Thanks!

>
>
>
> 在 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