OpenJDK 12-dev fastdebug for X86: Native memory allocation (malloc) failed to allocate 3276800 bytes for CodeCache: no room for Interpreter

[Leslie Zhai]

Hi Erik,

Thanks for your response!


在 2018年09月17日 17:19, Erik Österlund 写道:
> Hi Leslie,
>
> InterpreterCodeSize is a VM-private variable. I recommend not changing 
> it unless you added lots of interpreter code that causes you to run 
> into the assert suggesting you need more memory, in at least one 
> configuration. This value needs to be at least large enough to fit the 
> interpreter in all supported configurations, and then yet a bit longer 
> for headroom so we don't have to update it every time somebody makes a 
> change to the interpreter interpreter code.
>
I need to find out the root cause why need much larger 
`InterpreterCodeSize` than X86,  but my sincere thanks will goto Volker 
owing to *no* more waste in the CodeCache after applied his patch:
http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-September/007847.html

> Obviously, if you set the value too high, you will exhaust your code 
> cache, unless you add memory to the -XX:ReservedCodeCacheSize to 
> accommodate for that. The particular test you are running is running 
> with a very small code cache size, so it does not come as a surprise 
> that you exhaust it by making the interpreter code reservation very large.
I can feel what Albert feel :)
http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-September/007839.html

>
>
> I would suggest sending follow-up questions regarding the interpreter 
> to hotspot-runtime-dev, and not jdk-dev to reduce noise on this list.
Sorry for my wrong posting!

>
> Hope this explanation helps.
>
> /Erik
>
> On 2018-09-17 09:52, Leslie Zhai wrote:
>> Hi Erik,
>>
>> I want to verify JDK-8199417 with OpenJDK 12-dev fastdebug for X86:
>>
>> http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-September/007839.html 
>>
>>
>> $ hg log | head
>>
>> changeset:   51761:5f868838bc5f
>> tag:         tip
>> user:        weijun
>> date:        Mon Sep 17 14:52:44 2018 +0800
>> summary:     8210736: jdk/javax/xml/crypto/dsig/GenerationTests.java 
>> slow on linux
>>
>> $ ./configure --with-debug-level=fastdebug 
>> --with-boot-jdk=/home/xiangzhai/jdk-10.0.2 --disable-warnings-as-errors
>>
>> Then *deliberately* changed `InterpreterCodeSize` too big, for 
>> example 800K:
>>
>> diff -r 5f868838bc5f 
>> src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
>> --- a/src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp Mon 
>> Sep 17 14:52:44 2018 +0800
>> +++ b/src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp Mon 
>> Sep 17 15:43:09 2018 +0800
>> @@ -57,8 +57,12 @@
>>  // Run with +PrintInterpreter to get the VM to print out the size.
>>  // Max size with JVMTI
>>  #ifdef AMD64
>> +#ifdef PRODUCT
>>  int TemplateInterpreter::InterpreterCodeSize = JVMCI_ONLY(268) 
>> NOT_JVMCI(256) * 1024;
>>  #else
>> +int TemplateInterpreter::InterpreterCodeSize = 800 * 1024;
>> +#endif
>> +#else
>>  int TemplateInterpreter::InterpreterCodeSize = 224 * 1024;
>>  #endif // AMD64
>>
>>
>> $ make CONF=fastdebug images
>>
>> $ jtreg -vmoptions:"-XX:+UnlockDiagnosticVMOptions 
>> -XX:+PrintInterpreter" -dir:/home/xiangzhai/jdk/test/hotspot/jtreg 
>> -verbose:all -a -ignore:quiet -timeoutFactor:5 -agentvm 
>> -testjdk:/home/xiangzhai/jdk/build/linux-x86_64-normal-server-fastdebug/jdk 
>> compiler/startup/SmallCodeCacheStartup.java
>>
>> STDOUT:
>> Command line: 
>> [/home/xiangzhai/jdk/build/linux-x86_64-normal-server-fastdebug/jdk/bin/java 
>> -cp 
>> /home/xiangzhai/JTwork/classes/compiler/startup/SmallCodeCacheStartup.d:/home/xiangzhai/jdk/test/hotspot/jtreg/compiler/startup:/home/xiangzhai/JTwork/classes/test/lib:/home/xiangzhai/jtreg/lib/javatest.jar:/home/xiangzhai/jtreg/lib/jtreg.jar 
>> -XX:ReservedCodeCacheSize=3m -XX:CICompilerCount=64 -Xcomp -version ]
>> STDERR:
>>  stdout: [[0.014s][warning][codecache] CodeCache is full. Compiler 
>> has been disabled.
>> [0.015s][warning][codecache] Try increasing the code cache size using 
>> -XX:ReservedCodeCacheSize=
>> CodeCache: size=3072Kb used=32Kb max_used=33Kb free=3039Kb
>>  bounds [0x00007f99c2e6f000, 0x00007f99c316f000, 0x00007f99c316f000]
>>  total_blobs=7 nmethods=0 adapters=0
>>  compilation: disabled (not enough contiguous free space left)
>>               stopped_count=1, restarted_count=0
>>  full_count=0
>> #
>> # There is insufficient memory for the Java Runtime Environment to 
>> continue.
>> # Native memory allocation (malloc) failed to allocate 3276800 bytes 
>> for CodeCache: no room for Interpreter
>>
>> ----- 8< -------- 8< -------- 8< -------- 8< -------- 8< -------- 8< ---
>>
>> So there is the upper limit value for `InterpreterCodeSize`?  Is it 
>> able to workaround MIN(quadrupled, MAX_VALUE) for debug builds in 
>> order to accommodate for the additional debugging code?
>>
>> Please give me some suggestions, thanks a lot!
>>
>> Thanks,
>>
>> Leslie Zhai
>>
>>
>