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