RFR (S): 8016270: "CodeCache is full" message and compilation disabled, but codecache is not actually full

Chris Plummer chris.plummer at oracle.com
Wed Jul 31 18:19:31 PDT 2013


Hi,

Please review the following:

http://cr.openjdk.java.net/~cjplummer/8016270/webrev.00/

The purpose of this fix is to prevent the compiler from being disabled 
due to a combination of fragmentation and a very large nmethod that 
cannot be allocated. I've added a new command line flag called 
StopCompilationFailedSize (defaults to 1k). If the allocation that fails 
is smaller than this size, then the compiler will still be disabled. If 
bigger, the compiler will remain enabled, allowing for smaller methods 
to still be compiled. However, the sweeper will still be invoked in 
hopes of making room for the large method so it eventually can be compiled.

The failed_allocation_size now passed into 
CompileBroker::handle_full_code_cache() defaults to 0, and is only 
explicitly passed in when an nmethod allocation fails. I figured this 
was the only place likely to see larger allocations, and other 
allocations would typically be well under 1k. However, if something like 
an adapter was over 1k and failed to allocate, no real harm is done. It 
just means the compiler won't be turned off. failed_allocation_size is 
really more of a hint for CompileBroker::handle_full_code_cache() and is 
not required to be accurate.

In CodeCache::print_summary in codeCache.cpp, I made a minor and 
somewhat related fix. I removed the word "contiguous" from the message 
when the compiler is currently disabled. It used to be true, but no 
longer is some fixes Nils did a while back.

I've verified that with this fix I no longer see the "codecache is full" 
messages when running Nashorn + v8 with a 20m codecache (normally is 
uses about 58m). Benchmark results aren't changing much, although the 
stdev seems to be lower with the fix. I think this is because 
compilation was almost always quickly re-enabled anyway because the 
codecache was normally in a state such that CodeCache::needs_flushing() 
would return false. In fact sometimes compilation would be enabled even 
before CompileBroker::handle_full_code_cache() had a chance to call 
CodeCache::print_summary(), which ended up showing that the compiler is 
enabled.

I've tested with JPRT, jck (vm), JTReg compiler tests, and 
vm.quick.testlist.

Chris


More information about the hotspot-compiler-dev mailing list