RFR(xs): 8202073: MetaspaceAllocationTest gtest shall lock during space creation

[coleen.phillimore at oracle.com]

This revision looks good also.  I think this is trivial and only 
requires one review and it's been out for 24 hours.
thanks,
Coleen

On 4/21/18 1:36 AM, Thomas Stüfe wrote:
> Hi all,
>
> may I have a second reviewer please.
>
> new webrev (I missed an include and broke the non-pch builds):
>
> http://cr.openjdk.java.net/~stuefe/webrevs/8202073-MetaspaceAllocationTest-gtest-shall-lock-during-space-creation/webrev.01/webrev/
>
> Thanks, Thomas
>
>
> On Fri, Apr 20, 2018 at 9:11 AM, Thomas Stüfe <thomas.stuefe at gmail.com> wrote:
>> May I please have reviews for this small fix to the
>> metaspace-allocate-stresstest-gtest:
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8202073
>>
>> webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8202073-MetaspaceAllocationTest-gtest-shall-lock-during-space-creation/webrev.00/webrev/
>>
>> MetaspaceAllocationTest mimicks ClassLoaderMetaspace creation,
>> allocation and destruction to stress metaspace allocation.
>>
>> So it runs outside the normal create-allocate-delete cycle in the VM.
>> For instance, there are no associated ClassLoaderData. So, the test
>> needs to mimick the surroundings of the VM.
>>
>> This means, when creating ClassLoaderMetaspace objects, the test needs
>> to lock its associated lock. In the VM, this happens in
>> ClassLoaderData::metaspace_non_null(), and there the associated lock
>> is pulled before allocation too.
>>
>> Thanks, Thomas