Bug ID: JDK-6306738 Memory leaks of C-heap allocated ResourceObjs

Versions (Unresolved/Resolved/Fixed)

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 b52Fixed

-
-
(This bug has been marked with lower priority as the leak is benign.)

Certain ResourceObjs are being allocated on the C heap using the
ResourceObj::C_HEAP argument to operator new without being properly
freed. operator delete for ResourceObj is a no-op, so the storage for
such objects must be freed after calling delete on the passed pointer
by calling FreeHeap on it as well. For example:

  my_ptr = new (ResourceObj::C_HEAP) MyClass();
  ...
  delete my_ptr;
  FreeHeap(my_ptr);

This idiom is used for example in Label::free() in assembler.hpp.

Most of the allocations of this type are for GrowableArrays being
allocated on the C heap. For these objects clear_and_deallocate() must
be called before freeing the storage. This is already being done in
most places but there are a few omissions. In some places the call of
operator delete has been elided. This is not incorrect, but for
consistency such allocation sites should be changed to follow the
pattern in Label::free() (clear_and_deallocate, delete, FreeHeap).

The relevant allocation sites for this group's code are attached.
hotspot/compiler2:
c2_baseline/src/share/vm/compiler/compileLog.cpp:19:  initialize(new(ResourceObj::C_HEAP) fileStream(fp));
   - _out is leaked in destructor
hotspot/compiler2:
src/share/vm/compiler/compileLog.cpp:19:  initialize(new(ResourceObj::C_HEAP) fileStream(fp));
   - _out is leaked in destructor

EVALUATION Fixed 6306746: Add assertions to GrowableArray and ResourceObj Fixed 6306730: Incorrect management of C-heap GrowableArrays (gc) Fixed 6306736: Incorrect management of C-heap (jvmti) Fixed 6306741: Memory leaks of C-heap allocated ResourceObjs (gc) Fixed 6306743: Memory leaks of C-heap allocated ResourceObjs (jvmti) Fixed 6306745: Memory leaks of C-heap allocated ResourceObjs (runtime) Fixed 6306738: Memory leaks of C-heap allocated ResourceObjs (c2) Require GrowableArrays whose elements are allocated on the C heap to also be allocated on the C heap. This prevents leaking the GrowableArray object itself or worse, having it go out of scope of it's containing ResourceMark. Which is usually why C_heap was used for the arguments themselves. I added a field to ResourceObj to track whether new allocates on c_heap, resource area, or arena, and implemented the ResourceObj::operator delete to call FreeHeap() if the allocation was on C heap. An assert was added to the delete() operator to check that delete can only be called on a C_HEAP allocated object, because it's not needed for resource and arena allocated objects. Also, added a GrowableArray destructor to call clear_and_deallocate() so that all callers need to do is: GrowableArray<T> *ga = new (C_HEAP) GrowableArray<T>(,true); ... delete ga; // call dtor and ResourceObj::operator delete() Also I removed NonPrintingResourceObj because it's supposedly an optimization of ResourceObj. In PRODUCT mode, the virtual print() functions aren't included anyway, so I didn't get the reason for the optimization. Timed runThese -full with fastdebug and it came out about the same, actually it came out faster(?). Also, fixed compilation warning from tagged stack interpreter putback. Fix verified: y Verified by: Fixed asserts that were found with instances of Resource allocated growable arrays with C_heap elements. PRT Other testing: nsk vm.nightly.testlist (derived from vm.quick.testlist) (include jvmti tests) with -client/-server runThese -full -client/-server Initial version reviewed by: Steve B, Alan B, Ken, Mandy, Ramki, John R Final version Reviewed by: Steve B, John C, Steve G, Vladimir, Alan B

07-09-2005

Relates :	JDK-6306741 - Memory leaks of C-heap allocated ResourceObjs
Relates :	JDK-6306745 - Memory leaks of C-heap allocated ResourceObjs
Relates :	JDK-6306743 - Memory leaks of C-heap allocated ResourceObjs