RFR(S): 8236938: [TESTBUG] JFR event MetaspaceAllocationFailure is not tested

Thomas Stüfe thomas.stuefe at gmail.com
Mon Mar 2 18:58:32 UTC 2020


All still good.

...Thomas

On Mon, Mar 2, 2020 at 7:55 PM <mikhailo.seledtsov at oracle.com> wrote:

> Thank you Thomas for review.
>
> For the record, I have updated the webrev based on your review feedback
> (updated the @run statements):
>
> http://cr.openjdk.java.net/~mseledtsov/8236938.02/
>
>
> Thanks,
>
> Misha
>
>
> On 2/28/20 9:52 PM, Thomas Stüfe wrote:
>
> Hi Mikhailo,
>
> On Sat, Feb 29, 2020 at 1:05 AM <mikhailo.seledtsov at oracle.com> wrote:
>
>> Hi Thomas,
>>
>>    Thank you for review. Please see my comments inline.
>> On 2/27/20 11:15 AM, Thomas Stüfe wrote:
>>
>> Hi Mikhailo,
>>
>> looks good to me. Cannot comment on the effects of the class renaming.
>>
>> The test is of course vulnerable against changes in the metaspace usage
>> of the base jdk but I do not see how that could be changed. Make sure you
>> test with and without CDS enabled since if CDS is not enabled or does not
>> work the base JDK will use a lot more Metaspace and 20M may not be enough.
>> Or, make sure CDS is always enabled and working.
>>
>> Good point, thanks.
>>
>> I have added -Xshare:off to the @run params to make the test more
>> deterministic. And I quickly ran into OOME:Metaspace, hence I increased the
>> MaxMetaspaceSize to 100M.
>>
>> Here is a new @run statement:
>>
>>  * @run main/othervm -Xmx1G -XX:MaxMetaspaceSize=100M
>>  *      -XX:StartFlightRecording -Xshare:off
>>  *      jdk.jfr.event.runtime.TestMetaspaceAllocationFailure
>>  */
>>
>>
>> That is actually better than what I proposed.
>
>
>> If you want to be really thorough you may want to check exhaustion on
>> -XX:CompressedClassSpaceSize (with infinite MaxMetaspaceSize) too. As a
>> rough guide, each loaded class takes between 512 and 1K of space.
>>
>>  Thanks. I have added another @run to the same test using
>> CompressedClassSpaceSize:
>>
>>  * @run main/othervm -Xmx1G -XX:CompressedClassSpaceSize=100M
>>  *      -XX:StartFlightRecording -Xshare:off
>>  *      jdk.jfr.event.runtime.TestMetaspaceAllocationFailure
>>
>> It works, I am able to provoke the MetaspaceAllocationFailure JFR event.
>>
>> I will do some more testing on multiple platforms.
>>
>>
>> Great.
>
>> Thank you,
>>
>> Misha
>>
>>
>> ..Thomas
>
>
>
>> Cheers, Thomas
>>
>> On Thu, Feb 27, 2020 at 4:51 PM <mikhailo.seledtsov at oracle.com> wrote:
>>
>>> Please review this new test for JFR event MetaspaceAllocationFailure.
>>>
>>> The test fills the metaspace by generating classes in a loop, until the
>>> desired event is delivered to the receiver.
>>> By creating a new instance of class loader for each iteration test
>>> allows metaspace to be cleaned up once MetaspaceAllocationFailure
>>> condition is detected, thus not causing full-blown OOME. However, on
>>> occasion, it may happen, hence the try/catch clause.
>>> Ran this at least 100 times, works well and reliably.
>>>
>>> Also moved the class generator utility from Runtime test library to
>>> common test library; renamed it to avoid name clash with
>>> another already existing GeneratingClassLoader.
>>>
>>>      JBS: https://bugs.openjdk.java.net/browse/JDK-8236938
>>>      Webrev: http://cr.openjdk.java.net/~mseledtsov/8236938.01/
>>>      Testing:
>>>          1. Ran over 100 times on Linux, Windows and MAC: All PASS
>>>          2. Ran all runtime tests that rely on the class loader
>>> generator runtime library.
>>>
>>>
>>> Thank you,
>>> Misha
>>>
>>>


More information about the hotspot-jfr-dev mailing list