RFR: 8203885: ConcurrentLocksDump::dump_at_safepoint() should not allocate array in resource area
Per Liden
per.liden at oracle.com
Mon May 28 12:16:52 UTC 2018
ConcurrentLocksDump::dump_at_safepoint() creates a GrowableArray, which
gets allocated in a resource area. This array is than passed down a call
chain, where it can't control that another ResourceMark isn't created.
In the leaf of this call chain, a closure (FindInstanceClosure) is
executed, which appends to the array, which means it might need to be
resized. This doesn't work if a new ResourceMark has been created, since
the array resize will happen in a nested ResourceArea context. As a
result, the append operation fails in GenericGrowableArray::check_nesting().
This has so far gone unnoticed because CollectedHeap::object_iterate()
in existing collectors typically don't create new ResourceMarks. This is
not true for ZGC (and potentially other concurrent collectors), which
needs to walk thread stacks, which in turn requires a ResourceMark.
The proposed fix is to make this array C Heap allocated.
Bug: https://bugs.openjdk.java.net/browse/JDK-8203885
Webrev: http://cr.openjdk.java.net/~pliden/8203885/webrev.0
Testing: hs-tier{1,3}
/Per
More information about the hotspot-dev
mailing list