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

[Jie Fu]

On Mon, 24 May 2021 09:10:01 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> this will, however, only solve the problem w/ the test; but I also share Thomas' [concern](https://github.com/openjdk/jdk/pull/4140#issuecomment-845836298)[*], we shouldn't need 1g (or even .5g) of heap space to eat up 20m of metaspace (even w/ small classes like `AnonkTestee01`), so there seems to be an underlying defect in `linux-aarch64` build, which will need to be investigated/addressed separately.
>> 
>> -- Igor
>> 
>> [*] 
>>> What I am concerned about is that with there should not be that much variance in how much heap space we use. Sure you can set it to 1g or 2g, but something is clearly off. I get by on Linux x64 with 128m, on 32bit x86 with 256m (since we don't have CompressedClassPointers we need somewhat more heap). But needing 1g on aarch64 seems weird.
>
>> 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.

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

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