-
Enhancement
-
Resolution: Unresolved
-
P4
-
8, 11, 14, 15
There is the indirection to call form Java to runtime:
x86_64.ad:
enc_class Java_To_Runtime(method meth) %{
// No relocation needed
MacroAssembler _masm(&cbuf);
__ mov64(r10, (int64_t) $meth$$method);
__ call(r10);
%}
...which ends up taking quite a bit of space (13 bytes):
0x00007fd2884362a8: movabs $0x7fd2a010c520,%r10
0x00007fd2884362b2: callq *%r10 ;*invokestatic nanoTime
0x00007fd2884362b5: ...
If we avoid that indirection, by calling to literal with proper reloc type (runtime call), then we take only 5 bytes:
0x00007f5d84434ac8: callq 0x00007f5d9c5aa5b0 ; invokestatic nanoTime
0x00007f5d84434acd: ...
So it improves code density.
This also enables better annotation in generated code. For example, Shenandoah barriers slowpath calls (emitted with CallLeaf) currently show up like this:
0x00007faf7c4333ed: mov %rax,%rdi
0x00007faf7c4333f0: movabs $0x7faf94b72fd0,%r10
0x00007faf7c4333fa: callq *%r10
...and with the patch above, decoder finally grasps what that literal is pointing to:
0x00007f5d8442f7e5: mov %rax,%rdi
0x00007f5d8442f7e8: callq 0x00007f5d9c739060 ; {runtime_call ShenandoahRuntime::load_reference_barrier_narrow(oopDesc*, unsigned int*)}
Proof-of-concept patch:
https://cr.openjdk.java.net/~shade/8244521/webrev.01/
Major caveat: there is actually no guarantee runtime call is near so we can do rip-based encoding. The size estimate needs to be adjusted for those cases...
x86_64.ad:
enc_class Java_To_Runtime(method meth) %{
// No relocation needed
MacroAssembler _masm(&cbuf);
__ mov64(r10, (int64_t) $meth$$method);
__ call(r10);
%}
...which ends up taking quite a bit of space (13 bytes):
0x00007fd2884362a8: movabs $0x7fd2a010c520,%r10
0x00007fd2884362b2: callq *%r10 ;*invokestatic nanoTime
0x00007fd2884362b5: ...
If we avoid that indirection, by calling to literal with proper reloc type (runtime call), then we take only 5 bytes:
0x00007f5d84434ac8: callq 0x00007f5d9c5aa5b0 ; invokestatic nanoTime
0x00007f5d84434acd: ...
So it improves code density.
This also enables better annotation in generated code. For example, Shenandoah barriers slowpath calls (emitted with CallLeaf) currently show up like this:
0x00007faf7c4333ed: mov %rax,%rdi
0x00007faf7c4333f0: movabs $0x7faf94b72fd0,%r10
0x00007faf7c4333fa: callq *%r10
...and with the patch above, decoder finally grasps what that literal is pointing to:
0x00007f5d8442f7e5: mov %rax,%rdi
0x00007f5d8442f7e8: callq 0x00007f5d9c739060 ; {runtime_call ShenandoahRuntime::load_reference_barrier_narrow(oopDesc*, unsigned int*)}
Proof-of-concept patch:
https://cr.openjdk.java.net/~shade/8244521/webrev.01/
Major caveat: there is actually no guarantee runtime call is near so we can do rip-based encoding. The size estimate needs to be adjusted for those cases...