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.