RFR: JDK-8212218: [TESTBUG] runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryErrorInMetaspace.java timed out

Thomas Stüfe thomas.stuefe at gmail.com
Tue Oct 13 16:14:17 UTC 2020


No. I can remove it if you prefer.

On Tue, Oct 13, 2020, 18:13 Yumin Qi <minqi at openjdk.java.net> wrote:

> On Tue, 13 Oct 2020 15:16:03 GMT, Thomas Stuefe <stuefe at openjdk.org>
> wrote:
>
> > Hi,
> >
> > this is a very simple test fix.
> >
> > TestHeapDumpOnOutOfMemoryErrorInMetaspace tests that Metaspace OOMs
> result in heap dumps if VM had been started
> > with -XX:+HeapDumpOnOutOfMemoryError.
> > The test fills Metaspace up to the limit (MaxMetaspaceSize) to provoke a
> Metaspace OOM. It sets MaxMetaspaceSize to 64m
> >
> > 64m gives us room for about ~62000 classes with the current VM. With
> JEP387, this becomes more like 68000 classes.
> >
> > 6x000 classes are a lot and if test runs on a debug VM they cause long
> verification times from compiler dependency
> > checks as well as CLDG verification. Both verifications behave
> quadratic. On our slow ppc machines this often leads to
> > timeouts (test takes about 22 minutes).  I lowered MaxMetaspaceSize to
> 16m which is fine for this test and reduces the
> > number of loaded classes to ~12000 classes resp 15000 with JEP387. This
> eases verification costs a lot.
> > I also switch off compiler dependency checks because a number of similar
> runtime tests do the same.
> >
> > I left it at that because that brings down test time on our ppc machine
> to ~30 seconds, which is fine.
>
> Is the copyright change necessary?
>
>
>
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/637
>


More information about the hotspot-runtime-dev mailing list