JDK-6306746 : Add assertions to GrowableArray and ResourceObj
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 6
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2005-08-05
  • Updated: 2012-10-08
  • Resolved: 2005-09-17
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
Related Reports
Relates :  
Relates :  
Relates :  
Description
A longstanding bug (6306530) recently came to light in which a
GrowableArray was being allocated with the "C_heap" argument set to
true but the GrowableArray itself (a ResourceObj) was being allocated
without the ResourceObj::C_HEAP flag passed to operator new. This
caused the GrowableArray object (containing the nesting, arena and
data pointers) to be accidentally destroyed and overwritten.

While in some cases it is not incorrect to allocate a GrowableArray in
this fashion (for example, when the initial allocation is performed at
a well-known ResourceMark nesting but modifications to it will not
be), in general this is problematic usage and should be disallowed. In
debug mode, ResourceObj and NonPrintingResourceObj should record
whether they were allocated from the C heap, and the GrowableArray
constructor should assert that if the C_heap argument is true, that
the GrowableArray itself was allocated from the C heap.
-
-
-
-
-
-

Comments
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

EVALUATION I added an assertion for growable arrays that assert that if they elements are allocated out of c_heap that the growable array itself must be allocated out of C_heap. The places where the assert fired were changed to allocate the growableArray out of C heap. This seems like a worthwhile simplification of the growable array allocation, and in fact by asserting that the Growable Array _and_ it's elements are C heap allocated, I can change clear_and_deallocate to call 'delete this' and FreeHeap(this), thus making it impossible to forget to call these and leak memory (unless clear_and_deallocate isn't called). This will make our lives easier.
19-08-2005