JDK-2129621 : Memory leaks of C-heap allocated ResourceObjs
  • Type: Backport
  • Backport of: JDK-6306741
  • Component: hotspot
  • Sub-Component: gc
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2005-09-07
  • Updated: 2011-02-16
  • Resolved: 2006-11-20
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.
Other JDK 6
1.4.2_14 b01Fixed 6Fixed
Description
Certain GrowableArrays are being allocated with the "C_heap" flag set
to true but without the ResourceObj::C_HEAP flag being passed to
operator new for the GrowableArray object itself. This is a problem
because it is very easy to accidentally allocate the GrowableArray
underneath a ResourceMark which is later cleared, which will cause the
storage for the GrowableArray object itself (including nesting, arena,
and data pointer flags) to be overwritten later. This can cause
crashes in product mode and/or assertion failures in debug mode. In
the absence of assertions that the allocation class of the
GrowableArray matches that of its contained data array, these
allocation sites should be fixed to pass ResourceObj::C_HEAP as
argument to operator new. It is possible that these sites are benign
because the allocation is being done at a point where the ResourceMark
nesting is known, but if we add assertion checking later then these
allocation sites will fail.

When making this change the responsible engineer should be careful not
to introduce new memory leaks. In particular, the following cleanup
sequence for these arrays should be obeyed:

  array->clear_and_deallocate();
  delete array; // call destructors, but ResourceObj destructor
                // doesn't free memory which was allocated in 
                // the C-heap with malloc
  FreeHeap(Array);  // ... so use this to free the memory

See Label::free() in assembler.hpp for an example.

The relevant allocation sites for this group's code are attached.

------------------------------------------------------------------

Adding specifics to the description for gc:

hotspot/garbage_collector:
src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp:540:      _preserved_oop_stack = new (ResourceObj::C_HEAP) GrowableArray<oop>(40, true);
src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp:539:      _preserved_mark_stack = new (ResourceObj::C_HEAP) GrowableArray<markOop>(40, true);
src/share/vm/gc_implementation/shared/markSweep.cpp:118:      _preserved_mark_stack = new (ResourceObj::C_HEAP) GrowableArray<markOop>(40, true);
src/share/vm/gc_implementation/shared/markSweep.cpp:119:      _preserved_oop_stack = new (ResourceObj::C_HEAP) GrowableArray<oop>(40, true);
   - stacks are deleted but FreeHeap is not called on them
src/share/vm/memory/defNewGeneration.cpp:595:      _objs_with_preserved_marks = new (ResourceObj::C_HEAP)
src/share/vm/memory/defNewGeneration.cpp:597:      _preserved_marks_of_objs = new (ResourceObj::C_HEAP)
   - stacks are deleted but FreeHeap is not called on them; also, no
     clear_and_deallocate is called (** SERIOUS **)
   - genMarkSweep.cpp: _preserved_mark_stack and _preserved_oop_stack:
     call FreeHeap after operator delete

Above Information was written  by kenneth.russell [2005-08-05 00:31]

Comments
EVALUATION Fix memory leaks in GrowableArrays found in tiger sources that occur during GC. EG. need to call + _promo_failure_scan_stack->clear_and_deallocate(); delete _promo_failure_scan_stack; + FreeHeap(_promo_failure_scan_stack); instead of just 'delete' because 'delete' doesn't return the C_HEAP memory used by the elements. *** (#1 of 2): 2005-09-07 13:51:16 PDT ###@###.### Fixed 6306741: Fix memory leaks in GrowableArrays used by GC. Backport memory leak cleanups in GC because customers complain when gc leaks memory more than in other places. Fix verified (y/n): y Verified by: ran GCBasher for a while, not easy to verify otherwise Other testing: runThese -jck -client/-server (which uses parallel and serial gc) Webrev (for tiger): http://jruntime.east/~coleenp/webrev/6306741_bp/ Reviewed by: keith, ramki, jrose, kbr Approved by: Darin R. *** (#2 of 2): 2005-09-27 07:47:36 PDT ###@###.###
27-09-2005

EVALUATION See Parent CR.
27-09-2005