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