RFR: 8358756: [s390x] Test StartupOutput.java crash due to CodeCache size

Damon Fenacci dfenacci at openjdk.org
Wed Jun 11 12:52:30 UTC 2025


On Wed, 11 Jun 2025 04:33:30 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

> There isn't enough initial cache present which can let the interpreter mode run freely. So before even we reach to the compiler phase and try to bail out, in case there isn't enough space left for the stub compilation, JVM crashes. Idea is to increase the Initial  cache size and make it enough to run interpreter mode at least.

Thanks @offamitkumar.
The idea behind the [PR](https://github.com/openjdk/jdk/pull/23630) that changed this is that it would check randomly around the amount of code cache that would be just enough for the compilers to start (or not). So, before that PR it would sometimes crash instead of terminating gently. Does adding `800k` to the initial code cache for s390 do that? Did you try before that [PR](https://github.com/openjdk/jdk/pull/23630) (or temporarily reverting it) to see if it crashes?

test/hotspot/jtreg/compiler/startup/StartupOutput.java line 66:

> 64:         Process[] pr = new Process[200];
> 65:         for (int i = 0; i < 200; i++) {
> 66:             int initialCodeCacheSizeInKb = 800 + rand.nextInt(400) + (Platform.isS390x() ? 800 : 0);

It is just a stylistic issue but I'd rather adapt the fist constant (`800`)  depending on the platform with something like:
`int initialCodeCacheSizeInKb = minInitialSize + rand.nextInt(400);`

and `minInitialSize` set depending on the platform before the loop.

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

PR Review: https://git.openjdk.org/jdk/pull/25741#pullrequestreview-2916977944
PR Review Comment: https://git.openjdk.org/jdk/pull/25741#discussion_r2140032847


More information about the hotspot-compiler-dev mailing list