RFR: 8326615: C1/C2 don't handle allocation failure properly during initialization (RuntimeStub::new_runtime_stub fatal crash) [v5]
Vladimir Kozlov
kvn at openjdk.org
Tue Jul 2 18:08:19 UTC 2024
On Tue, 2 Jul 2024 06:57:56 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:
>> I suggest instead adjust CodeCache minimal size check when JIT compilers are enabled in `CompilerConfig::check_args_consistency()`. We check `CodeCacheMinimumUseSpace` value their which is 400Kb only. It could be enough to run with `-Xint` (Interpreter only). But it is definitely not enough to run with JIT compilers.
>
>> I suggest instead adjust CodeCache minimal size check when JIT compilers are enabled in `CompilerConfig::check_args_consistency()`. We check `CodeCacheMinimumUseSpace` value their which is 400Kb only. It could be enough to run with `-Xint` (Interpreter only). But it is definitely not enough to run with JIT compilers.
>
> @vnkozlov thanks for your insights!
> I've tried to figure out an estimate of a bare minimum code cache size for interpreter/C1/C2/both for a couple of architectures (basically by running `java -version`):
> | | Int | C1 only | C2 only | C1/C2 tiered |
> |----------------|------|---------|---------|--------------|
> | linux-x64 | 680k | 4m | 900k | 2.2m |
> | macosx-aarch64 | 580k | 3m | 800k | 1.5m |
> | linux-aarch64 | 520k | 3.8m | 800k | 1.5m |
>
> (interesting that C2 needs less code cache than C1 but I guess it could also be due to the fact that its thread might actually exit before it properly starts)
>
> 800k for the interpreter alone and 5 times as much (4m) when C1 or C2 are running might be good minima. What do you think?
@dafedafe Did you run on avx512 x64 machine? We generate a lot of avx512 specific stubs for C2's intrinsics. We need to count them.
How you got 4Mb for C1 only? I got:
java -XX:+PrintCodeCache -XX:+TieredCompilation -XX:TieredStopAtLevel=1 -version
...
CodeCache: size=49152Kb used=1084Kb max_used=1084Kb free=48067Kb
-------------
PR Comment: https://git.openjdk.org/jdk/pull/19280#issuecomment-2203986935
More information about the hotspot-compiler-dev
mailing list