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

[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