RFR: 8351965: [leyden] Skip C2 AOT code if C2 preload AOT code trapped [v6]

[Vladimir Ivanov]

On Wed, 19 Mar 2025 09:18:00 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`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix Minimal build

I still feel a bit uneasy about the proposed change. 

> Regardless, I believe that if preload code traps, then non-preload code would also trap in those conditions, since both versions were compiled in the same environment.

Unless it caused by a divergence in behavior between training and production runs, I'd attribute it to a bug in our code where we misinterpret training data (e.g., excluding the class from the archive, not preloading class in all loaders, not preresolving relevant CP entry, etc). 

Before making a decision, I'd like to understand what's the real cause of the trap at `new NameImpl(this, string)` in your case.


[0.047s][debug  ][deoptimization] cid= 333     level=4 com.sun.tools.javac.util.StringNameTable::fromString(Ljava/lang/String;)Lcom/sun/tools/javac/util/Name; trap_bci=28 unloaded reinterpret pc=0x000071945803a2c0 relative_pc=0x00000000000003c0

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

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