RFR: 8351965: [leyden] Skip installing C2 AOT code if C2 precompiled AOT code trapped

[Aleksey Shipilev]

On Thu, 13 Mar 2025 16:43:23 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> This is clearly visible in compilation logs:
> 
> 
>      43    W0.1    Q8.1    C0.0    293      AP 4       com.sun.tools.javac.util.StringNameTable::fromString (50 bytes)
> [0.049s][debug  ][deoptimization] cid= 293     level=4 com.sun.tools.javac.util.StringNameTable::fromString(Ljava/lang/String;)Lcom/sun/tools/javac/util/Name; trap_bci=28 unloaded reinterpret pc=0x00007c6bd7e4e7ac relative_pc=0x000000000000068c
>      49                            293      AP 4       com.sun.tools.javac.util.StringNameTable::fromString (50 bytes)   made not entrant
>      49    W0.2    Q0.0    C0.3   1394         2       com.sun.tools.javac.util.StringNameTable::fromString (50 bytes)
>      90                           1394         2       com.sun.tools.javac.util.StringNameTable::fromString (50 bytes)   made not entrant
>      90    W0.0    Q0.0    C0.1   1867      A  4       com.sun.tools.javac.util.StringNameTable::fromString (50 bytes)
> [0.098s][debug  ][deoptimization] cid=1867     level=4 com.sun.tools.javac.util.StringNameTable::fromString(Ljava/lang/String;)Lcom/sun/tools/javac/util/Name; trap_bci=28 unloaded reinterpret pc=0x00007c6bd7ebcb58 relative_pc=0x00000000000005d8
>      98                           1867      A  4       com.sun.tools.javac.util.StringNameTable::fromString (50 bytes)   made not entrant
>     104    W0.0    Q0.0    C0.3   1942         2       com.sun.tools.javac.util.StringNameTable::fromString (50 bytes)
>     130                           1942         2       com.sun.tools.javac.util.StringNameTable::fromString (50 bytes)   made not entrant
>     130    W1.0    Q0.7   C13.3   1968         4       com.sun.tools.javac.util.StringNameTable::fromString (50 bytes)
> 
> 
> So the AP4 method was preloaded, then it trapped and got replaced by T2 method, which eventually got to C2, at which point we loaded A4 method. That method trapped _at the same bci_, so we are back at T2, then then to real T4. So we have spent one deopt cycle unnecessarily, and the code was in T2 for twice as long.
> 
> I don't think we would be able to fully tame uncommon traps from the preload code, so fixing this gap is valuable.
> 
> `decompile_count()` is only updated by C2, so we can just check it directly.
> 
> Additional testing:
>  - [x] Ad-hoc benchmarks
>  - [x] Linux x86_64 server fastdebug, `runtime/cds`

Note the improvements in `User` time, these are the compilations we do not do. This somewhat reflects in end-to-end timings too.

`JavacBenchApp 1`:


Benchmark 1: build/linux-x86_64-server-release/images/jdk/bin/java -Xms64m -Xmx8g \
   -XX:+UseSerialGC -cp JavacBenchApp.jar -XX:AOTCache=app.aot JavacBenchApp 1

# Before
  Time (mean ± σ):     180.2 ms ±   3.5 ms    [User: 349.9 ms, System: 67.2 ms]
  Range (min … max):   173.5 ms … 184.9 ms    30 runs

# After
  Time (mean ± σ):     176.5 ms ±   2.3 ms    [User: 299.7 ms, System: 65.7 ms]
  Range (min … max):   173.4 ms … 181.0 ms    30 runs


`JavacBenchApp 50`:


Benchmark 1: build/linux-x86_64-server-release/images/jdk/bin/java -Xms64m -Xmx8g \
   -XX:+UseSerialGC -cp JavacBenchApp.jar -XX:AOTCache=app.aot JavacBenchApp 50

# Before
  Time (mean ± σ):     467.4 ms ±   8.3 ms    [User: 2150.0 ms, System: 172.9 ms]
  Range (min … max):   455.5 ms … 488.6 ms    30 runs

# After
  Time (mean ± σ):     453.7 ms ±   4.8 ms    [User: 1567.3 ms, System: 146.4 ms]
  Range (min … max):   446.7 ms … 468.7 ms    30 runs

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

PR Comment: https://git.openjdk.org/leyden/pull/48#issuecomment-2734312638