RFR(S): 8236938: [TESTBUG] JFR event MetaspaceAllocationFailure is not tested
Thomas Stüfe
thomas.stuefe at gmail.com
Thu Feb 27 19:15:25 UTC 2020
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.
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.
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