JDK-7008325 : CodeCache exhausted on sparc starting from hs20b04
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: hs20
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: x86
  • Submitted: 2010-12-21
  • Updated: 2012-02-01
  • Resolved: 2011-03-08
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6 JDK 7 Other
6u25Fixed 7Fixed hs20Fixed
Related Reports
Relates :  
JDK-6961690 - load oops from constant table on SPARC
Relates :  
JDK-7009641 - Don't use CodeCache for allocations if it is already full
Description
Tests
nsk/stress/jck60/jck60026
bigapps/runThese/stability
run out of native resources and fails with java.lang.OutOfMemoryError: requested 1824 bytes for CodeCache: no room for vtable chunks.

There were no such failure since codecache parameter for runThese was increased to 64M.
It seems like VM require more native.

Issue is appears only on sparcs.

Report:
(http://sqeweb.sfbay/nfs/results/vm/gtee/HSX/PIT/VM/hs20/04/jdk7b122/product/bigapps/solaris-sparcv9/server/comp/solaris-sparcv9_bigapps__server_comp_runThese/runThese/hs_err_pid28881.log)

;; Using jvm: "/export/local/common/jdk/baseline/solaris-sparcv9/jre/lib/sparcv9/server/libjvm.so"
#
# A fatal error has been detected by the Java Runtime Environment:
#
# java.lang.OutOfMemoryError: requested 1824 bytes for CodeCache: no room for vtable chunks. Out of swap space?
#
#  Internal Error (vtableStubs.cpp:63), pid=28881, tid=330
#  Error: CodeCache: no room for vtable chunks
#
# JRE version: 7.0-b122
# Java VM: Java HotSpot(TM) 64-Bit Server VM (20.0-b04-internal-201012170509.et151817.hs20b04-ci compiled mode solaris-sparc compressed oops)
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#

See testrun example:
http://sqeweb.sfbay/nfs/results/vm/gtee/HSX/PIT/VM/hs20/04/jdk7b122/product/bigapps/solaris-sparcv9/server/comp/solaris-sparcv9_bigapps__server_comp_runThese/analysis.html
It does not look like CodeCache is exhausted:

Code Cache  [0xffffffff77800000, 0xffffffff7b800000, 0xffffffff7b800000)
 total_blobs=40649 nmethods=16532 adapters=501 free_code_cache=770368
Comments
PUBLIC COMMENTS The bug is that Compile::ScheduleAndBundle calls init_scratch_buffer_blob and later clear_scratch_buffer_blob to reset _scratch_buffer_blob and _scratch_locs_memory (setting to NULL). But the CompilerWrapper destructor only frees the _scratch_buffer_blob if it's non-null resulting in a CodeCache memory leak. The fix is to remove clear_scratch_buffer_blob completely and let init_scratch_buffer_blob free and allocate a new blob if required. Additionally I added some code that prints the largest free block in CodeCache::print_bounds (as found in the hs_err file).
29-12-2010
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/51bd2d261853
29-12-2010
SUGGESTED FIX The fix is to remove clear_scratch_buffer_blob completely and let init_scratch_buffer_blob free and allocate a new blob if required.
23-12-2010
EVALUATION The bug is that Compile::ScheduleAndBundle calls init_scratch_buffer_blob and later clear_scratch_buffer_blob to reset _scratch_buffer_blob and _scratch_locs_memory (setting to NULL). But the CompilerWrapper destructor only frees the _scratch_buffer_blob if it's non-null resulting in a CodeCache memory leak.
23-12-2010