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

[Vladimir Ivanov]

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_, which is really expected, 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`

I don't know whether it is a good heuristic for a general case. How much does it improve the behavior?

Most likely, repeated deoptimizations happen because compiled code happens to arrive much earlier than it happened during training run. (Unless training run suffered from the very same deoptimizations.) So, IMO the question boils down to whether it is beneficial to unconditionally reprofile/recompile or continue using AOTed code hoping for the best.

Also, there was a deoptimization which may already let interpreter fix some of the trap causes. 

Another point: I believe MDO should include archived data, so decompile count may report higher number than actually observed during current run.

Also, don't we try to avoid uncommon traps in preloaded code these days? So, a trap in preloaded code means there's something C2 can't get rid of.

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

PR Review: https://git.openjdk.org/leyden/pull/48#pullrequestreview-2682842878
PR Comment: https://git.openjdk.org/leyden/pull/48#issuecomment-2722099516