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

mikhailo.seledtsov at oracle.com mikhailo.seledtsov at oracle.com
Mon Mar 2 18:55:31 UTC 2020


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 
> <mailto: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
>>     <mailto: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