JDK-6375289 : BufferBlob leaks
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 1.4.2
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2006-01-20
  • Updated: 2010-04-03
  • Resolved: 2006-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
6 b75Fixed
Related Reports
Relates :  
JDK-6354559 - Labels can leak C heap memory
Relates :  
JDK-5101346 - JumpTables for X86
Relates :  
JDK-6847791 - crash in std_verified_entry
Description
To generate code for most types of the generated code (e.g. nmethod,
RuntimeStub, C2IAdapter, I2CAdapter, etc), a BufferBlob is created
first, code is generated in the BufferBlob, then a final CodeBlob of
the correct type is created and the generated code is copied over from the BufferBlob to the final CodeBlob. After that the BufferBlob should be freed. But some of the the temporary BufferBlobs created to help generating nmethods, RuntimeStubs, C2IAdapters and I2CAdapters are not freed afterwards. This is actually a leak in the CodeCache.

1. In file ciEnv.cpp:

a. In ciEnv::register_method():

A call "code_buffer->free_auto_blob()" is needed before the return in the if (bailed_out()) block.

b. In ciEnv::register_i2c_adapter():

A call "code_buffer->free_auto_blob()" is needed both before the return in the if (bailed_out()) block and after the call to I2CAdapter::new_i2c_adapter().

c. In ciEnv::register_c2i_adapter():

A call "code_buffer->free_auto_blob()" is needed both before the return in the if (bailed_out()) block and after the call to C2IAdapter::new_i2c_adapter().

2. In file compile.cpp:

In the Compile class constructor for compiling a runtime stub, a call "_code_buffer->free_auto_blob()" is needed after the call to RuntimeStub::new_runtime_stub().

2006-01-20 16:12:27.646  ###@###.###
 

An update from HP:

In general, this is a problem in all versions: 1.4.2, 5.0 and 6.0, although
the details about where fixes are needed might be different since code has
been changed between versions.

Also, instead of the suggestions I made in my bug report, I'd like to make
another suggestion of what I think is a better solution. That is, remove the
"code_buffer->free_auto_blob()" calls that were already in ciEnv.cpp.
Instead, make a destructor for Compile class, and calls "delete
_code_buffer" from Compile class's destructor. This way, with one delete,
temporary BufferBlobs created for all cases (nmethod, stubs, i2c adapter,
c2i adapter) will be freed.
Comments
SUGGESTED FIX This is the suggested fix for Mustang along with related changes. http://analemma.sfbay.sun.com/net/prt-archiver.sfbay/data/archived_workspaces/main/c2_baseline/2006/20060227123051.never.labels/workspace/webrevs/webrev-2006.02.27/index.html The tiger version will be more targetted.
27-02-2006
EVALUATION 1.4.2 and 1.5 roughly have the same problems with 1.5 having slightly fewer. Addtionally stubGenerator.cpp leaks a few small code blob at startup. 1.6 fixed the C2 problems but introduced some new ones related to expansion of code bufferes. As part of fixing 6354559 I'll be making CodeBuffer be stack allocated which will force their destructors to be called which will clean up these leaks up for mustang. In 1.4.2 and 1.5 a variant of the suggested fix of putting code in the CompileWrapper to free the blob is the right solution. The code for this already exists in 1.6.
26-01-2006