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