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

Erik Österlund erik.osterlund at oracle.com
Mon Sep 17 09:19:03 UTC 2018


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.

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 would suggest sending follow-up questions regarding the interpreter to 
hotspot-runtime-dev, and not jdk-dev to reduce noise on this list.
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
>
>



More information about the jdk-dev mailing list