RFR: 8351965: [leyden] Skip installing C2 AOT code if C2 precompiled AOT code trapped
Aleksey Shipilev
shade at openjdk.org
Fri Mar 14 09:20:08 UTC 2025
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`
OK, look through this.
Java code:
@Override
public Name fromString(String string) {
Name name = nameMap.get(string);
if (name == null) {
if (intern) {
string = string.intern();
}
name = new NameImpl(this, string); // <--- TRAPS HERE
nameMap.put(string, name);
}
return name;
}
Relevant bytecode:
public com.sun.tools.javac.util.Name fromString(java.lang.String);
descriptor: (Ljava/lang/String;)Lcom/sun/tools/javac/util/Name;
flags: (0x0001) ACC_PUBLIC
Code:
stack=4, locals=3, args_size=2
0: aload_0
1: getfield #21 // Field nameMap:Ljava/util/HashMap;
4: aload_1
5: invokevirtual #29 // Method java/util/HashMap.get:(Ljava/lang/Object;)Ljava/lang/Object;
8: checkcast #33 // class com/sun/tools/javac/util/Name
11: astore_2
12: aload_2
13: ifnonnull 48
16: aload_0
17: getfield #25 // Field intern:Z
20: ifeq 28
23: aload_1
24: invokevirtual #35 // Method java/lang/String.intern:()Ljava/lang/String;
27: astore_1
28: new #40 // class com/sun/tools/javac/util/StringNameTable$NameImpl <---- TRAPS HERE
31: dup
32: aload_0
33: aload_1
34: invokespecial #42 // Method com/sun/tools/javac/util/StringNameTable$NameImpl."<init>":(Lcom/sun/tools/javac/util/StringNameTable;Ljava/lang/String;)V
AP 4 code:
# Traps later here:
26 55 W0.0 Q20.7 C0.0 379 [0.056s][debug ][deoptimization] cid= 291 level=4 com.sun.tools.javac.util.StringNameTable::fromString(Ljava/lang/String;)Lcom/sun/tools/javac/util/Name; trap_bci=28 unloaded reinterpret pc=0x00007037e802ff10 relative_pc=0x0000000000000670
Compiled method (c2) 43 291 AP 4 com.sun.tools.javac.util.StringNameTable::fromString (50 bytes)
...
# this: rsi:rsi = 'com/sun/tools/javac/util/StringNameTable'
# parm0: rdx:rdx = 'java/lang/String'
[Entry Point]
# {method} {0x00000008006848b0} 'fromString' '(Ljava/lang/String;)Lcom/sun/tools/javac/util/Name;' in 'com/sun/tools/javac/util/StringNameTable'
# this: rsi:rsi = 'com/sun/tools/javac/util/StringNameTable'
# parm0: rdx:rdx = 'java/lang/String'
# [sp+0x50] (sp of caller)
0x00007037e802f8a2: mov 0x8(%rsi),%r10d
0x00007037e802f8a6: cmp 0x8(%rax),%r10d
0x00007037e802f8aa: jne 0x00007037e7851d40 ; {runtime_call Shared Runtime ic_miss_blob}
[Verified Entry Point]
0x00007037e802f8b0: mov %eax,-0x14000(%rsp)
0x00007037e802f8b7: push %rbp
0x00007037e802f8b8: sub $0x40,%rsp
0x00007037e802f8bc: cmpl $0x0,0x20(%r15)
0x00007037e802f8c4: jne 0x00007037e80301fe ; method entry is over
0x00007037e802f8ca: mov %rsi,%r14 ; %rsi, %r14 is now "this"
0x00007037e802f8cd: mov 0x14(%rsi),%r10d ; %r10 is "this.nameMap"
0x00007037e802f8d1: mov 0x8(%r10),%r8d ; type-check %r10 is java/util/HashMap
0x00007037e802f8d5: cmp $0x2ff6c8,%r8d ; {metadata('java/util/HashMap')}
0x00007037e802f8dc: jne 0x00007037e802fe8a
0x00007037e802f8e2: mov 0x24(%r10),%r11d ; inlined HashMap.get:
0x00007037e802f8e6: test %r11d,%r11d ; HashMap.table == null?
0x00007037e802f8e9: je 0x00007037e802fdd6 ; YES, so nameMap.get returns null, jump to slow path
...
0x00007037e802fdd6: mov %rdx,%r10
0x00007037e802fdd9: movzbl 0x10(%r14),%r11d ; %r14 is still "this", checking "this.intern"
0x00007037e802fdde: test %r11d,%r11d ; (intern == false)?
0x00007037e802fde1: je 0x00007037e802fefc ; YES, go uncommon trap
...
0x00007037e802fefc: mov $0x28,%esi
0x00007037e802ff01: mov %r14,%rbp
0x00007037e802ff04: mov %r10,(%rsp)
0x00007037e802ff08: vzeroupper
0x00007037e802ff0b: call 0x00007037e7823dc0 ; ImmutableOopMap {rbp=Oop [0]=Oop }
;*new {reexecute=0 rethrow=0 return_oop=0}
; - com.sun.tools.javac.util.StringNameTable::fromString at 28 (line 70)
; {runtime_call UncommonTrapBlob}
0x00007037e802ff10: nopl 0x6000808(%rax,%rax,1) ; {post_call_nop}
I checked that `A4` code follows the same pattern, not showing it here for brevity.
Note that none of this code checked the class init state at runtime. _So_, `A4` does not know to check if class was loaded, and just unconditionally traps. It would not help to remove traps in preload code, and it does not matter that interpreter loaded the class after the first deopt. A4 would trap regardless. This is why this proposed heuristics works: if we trapped from AP4, we are likely to trap from a similar code shape in A4.
I guess the better fix would be to make sure both AP4 and A4 versions are compiled with clinit-barriers everywhere?
-------------
PR Comment: https://git.openjdk.org/leyden/pull/48#issuecomment-2724108777
More information about the leyden-dev
mailing list