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

[Thomas Stüfe]

Thanks Coleen!

Will push.

Kind Regards, Thoams

On Mon, Apr 23, 2018 at 4:16 PM,  <coleen.phillimore at oracle.com> wrote:
>
> 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
>
>