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

coleen.phillimore at oracle.com coleen.phillimore at oracle.com
Mon Apr 23 14:16:46 UTC 2018

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

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

More information about the hotspot-runtime-dev mailing list