RFR: 8315843: C1: Use MDO offsets as int consts instead of intptr consts
Tobias Hartmann
thartmann at openjdk.org
Thu Sep 7 10:55:38 UTC 2023
On Thu, 7 Sep 2023 08:54:57 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:
> Noticed this when looking at C1 profiling code. We use MDO offsets as `intptrConst`, despite them being very small. This leads to loads with `movabs` with large immediates on x86. We can instead just load them as `intConst`-s. This affects tier3 profiling code only.
>
> Sample branch profiling hunk from C1 tier3 on x86_64:
>
>
> Before:
> 0x00007f269065ed02: test %edx,%edx
> 0x00007f269065ed04: movabs $0x7f260a4ddd68,%rax ; {metadata(method data for {method} …
> 0x00007f269065ed0e: movabs $0x138,%rsi
> ╭ 0x00007f269065ed18: je 0x00007f269065ed24
> │ 0x00007f269065ed1a: movabs $0x148,%rsi
> ↘ 0x00007f269065ed24: mov (%rax,%rsi,1),%rdi
> 0x00007f269065ed28: lea 0x1(%rdi),%rdi
> 0x00007f269065ed2c: mov %rdi,(%rax,%rsi,1)
> 0x00007f269065ed30: je 0x00007f269065ed4e
>
> After:
> 0x00007f1370dcd782: test %edx,%edx
> 0x00007f1370dcd784: movabs $0x7f12f64ddd68,%rax ; {metadata(method data for {method} …
> 0x00007f1370dcd78e: mov $0x138,%esi
> ╭ 0x00007f1370dcd793: je 0x00007f1370dcd79a
> │ 0x00007f1370dcd795: mov $0x148,%esi
> ↘ 0x00007f1370dcd79a: mov (%rax,%rsi,1),%rdi
> 0x00007f1370dcd79e: lea 0x1(%rdi),%rdi
> 0x00007f1370dcd7a2: mov %rdi,(%rax,%rsi,1)
> 0x00007f1370dcd7a6: je 0x00007f1370dcd7c4
>
>
> In the hunk above, this saves about 8 bytes. This leads to observable code space savings on larger tests, e.g. on `-Xcomp -XX:TieredStopAtLevel=... HelloWorld`.
>
>
> # Before
> tier1: nmethod code size : 426448 bytes
> tier2: nmethod code size : 463008 bytes
> tier3: nmethod code size : 910656 bytes
>
> # After
> tier1: nmethod code size : 426448 bytes
> tier2: nmethod code size : 463008 bytes
> tier3: nmethod code size : 892448 bytes (-2.0%)
>
>
> Additional testing:
> - [ ] Linux x86_64 fastdebug `tier1 tier2 tier3`
> - [ ] Linux AArch64 fastdebug `tier1 tier2 tier3`
I'm seeing failures during build:
[2023-09-07T10:47:14,379Z] # A fatal error has been detected by the Java Runtime Environment:
[2023-09-07T10:47:14,379Z] #
[2023-09-07T10:47:14,379Z] # Internal Error (/opt/mach5/mesos/work_dir/slaves/cd627e65-f015-4fb1-a1d2-b6c9b8127f98-S160475/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/e6602a1f-a21e-4e8c-a2e5-b8831688b712/runs/f932837c-4440-466e-accb-1c91993e1290/workspace/open/src/hotspot/cpu/x86/c1_LIR_x86.cpp:64), pid=10906, tid=11011
[2023-09-07T10:47:14,379Z] # assert(index()->is_illegal() || index()->is_double_cpu()) failed: wrong index operand
[2023-09-07T10:47:14,379Z] #
[2023-09-07T10:47:14,379Z] # JRE version: Java(TM) SE Runtime Environment (22.0) (fastdebug build 22-internal-2023-09-07-1002041.tobias.hartmann.jdk2)
[2023-09-07T10:47:14,379Z] # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 22-internal-2023-09-07-1002041.tobias.hartmann.jdk2, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
[2023-09-07T10:47:14,379Z] # Problematic frame:
[2023-09-07T10:47:14,380Z] # V [libjvm.so+0x7c514b] LIR_Address::verify() const+0x2bb
Current CompileTask:
C1: 397 4 3 java.lang.String::isLatin1 (19 bytes)
Stack: [0x000015056502b000,0x000015056512b000], sp=0x0000150565128a00, free space=1014k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0x7c514b] LIR_Address::verify() const+0x2bb (c1_LIR_x86.cpp:64)
V [libjvm.so+0x7a232c] LIRGenerator::profile_branch(If*, Instruction::Condition)+0x24c (c1_LIR.hpp:541)
V [libjvm.so+0x7badfd] LIRGenerator::do_If(If*)+0x27d (c1_LIRGenerator_x86.cpp:1532)
V [libjvm.so+0x79b4d3] LIRGenerator::do_root(Instruction*)+0x63 (c1_LIRGenerator.cpp:375)
V [libjvm.so+0x79f04e] non-virtual thunk to LIRGenerator::block_do(BlockBegin*)+0x5e (c1_LIRGenerator.cpp:372)
V [libjvm.so+0x765f31] BlockList::iterate_forward(BlockClosure*)+0x41 (c1_Instruction.cpp:889)
V [libjvm.so+0x7288d1] Compilation::emit_lir()+0x501 (c1_Compilation.cpp:260)
V [libjvm.so+0x72b177] Compilation::compile_java_method()+0x247 (c1_Compilation.cpp:406)
V [libjvm.so+0x72bb2b] Compilation::compile_method()+0x14b (c1_Compilation.cpp:475)
V [libjvm.so+0x72c2d4] Compilation::Compilation(AbstractCompiler*, ciEnv*, ciMethod*, int, BufferBlob*, bool, DirectiveSet*)+0x2b4 (c1_Compilation.cpp:602)
V [libjvm.so+0x72dd4e] Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xde (c1_Compiler.cpp:258)
V [libjvm.so+0x9fb390] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x980 (compileBroker.cpp:2283)
V [libjvm.so+0x9fc1c8] CompileBroker::compiler_thread_loop()+0x5f8 (compileBroker.cpp:1944)
V [libjvm.so+0xeb719c] JavaThread::thread_main_inner()+0xcc (javaThread.cpp:720)
V [libjvm.so+0x17a0f8a] Thread::call_run()+0xba (thread.cpp:220)
V [libjvm.so+0x149fe3a] thread_native_entry(Thread*)+0x12a (os_linux.cpp:785)
-------------
PR Comment: https://git.openjdk.org/jdk/pull/15612#issuecomment-1709937756
More information about the hotspot-compiler-dev
mailing list