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

[Thomas Stüfe]

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