RFR: 8267404: vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java failed with OutOfMemoryError [v3]

Thomas Stuefe stuefe at openjdk.java.net
Sun Jun 20 08:29:30 UTC 2021


On Fri, 11 Jun 2021 06:35:47 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>>> so there seems to be an underlying defect in `linux-aarch64` build, which will need to be investigated/addressed separately.
>> 
>> Yes, I think that makes sense since all of our linux-aarch64 platforms couldn't reproduce the OOME except those of Oracle's .
>
>> @DamonFool , the goal of this test is to check that in case of (nearly) exhaused metaspace defining classes via `MethodHandles.Lookup::defineHiddenClass` will lead to OOME, after your rewriting, this test doesn't serve that purpose anymore, now it just checks that runnig `java -version` w/ small metaspace will lead to OOME.
>> 
>> -- Igor
> 
> @tstuefe , do you also think we should revert this change and use `-XX:MaxRAMPercentage=25` to fix the bug?
> Thanks.

@DamonFool @iignatev guys, sorry for the late response. I am fine with restoring the test, I think Igor was right. 

I would love to understand the differences with aarch64s high heap usage though. Some thoughts. Do we manage on aarch64 to load the same amount of classes before OOME hits? Less? More? Does the way we create classes on aarch64 need somehow more java heap space?

It would be nice to compare metaspace state between "normal" platforms and aarch64 at the time oome hits. One way to do this would be to run the tests with -`XX:+PrintMetaspaceStatisticsAtExit` and compare the results. It would also be nice to know how many classes had been loaded at that point.

I'd be happy to take a look if someone does the tests. Unfortunately, I have no hardware to reproduce this problem.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4140


More information about the hotspot-runtime-dev mailing list