RFR: 8203885: ConcurrentLocksDump::dump_at_safepoint() should not allocate array in resource area

[Per Liden]

Thanks for reviewing, Thomas!

/Per

On 05/29/2018 07:59 AM, Thomas Stüfe wrote:
> Hi Per,
> 
> this looks good.
> 
> Best Regards, Thomas
> 
> On Mon, May 28, 2018 at 2:16 PM, Per Liden <per.liden at oracle.com> wrote:
>> 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