I got the below assembly list as result for JIT compilation for my java program.
mov 0x14(%rsp),%r10d
inc %r10d
mov 0x1c(%rsp),%r8d
inc %r8d
test %eax,(%r11) ; <--- this instruction
mov (%rsp),%r9
mov 0x40(%rsp),%r14d
mov 0x18(%rsp),%r11d
mov %ebp,%r13d
mov 0x8(%rsp),%rbx
mov 0x20(%rsp),%rbp
mov 0x10(%rsp),%ecx
mov 0x28(%rsp),%rax
movzbl 0x18(%r9),%edi
movslq %r8d,%rsi
cmp 0x30(%rsp),%rsi
jge 0x00007fd3d27c4f17
My understanding the test instruction is useless here because the main idea of the test is
The flags SF, ZF, PF are modified while the result of the AND is discarded.
and here we don't use these result flags.
Is it a bug in JIT or do I miss something? If it is, where the best place for reporting it? Thanks!
That must be the thread-local handshake poll. Look where %r11 is read from. If it is read from some offset off the %r15 (thread-local storage), that's the guy. See the example here:
0.31% ↗ ...70: movzbl 0x94(%r9),%r10d
0.19% │ ...78: mov 0x108(%r15),%r11 ; read the thread-local page addr
25.62% │ ...7f: add $0x1,%rbp
35.10% │ ...83: test %eax,(%r11) ; thread-local handshake poll
34.91% │ ...86: test %r10d,%r10d
╰ ...89: je ...70
It is not useless, it would cause SEGV once the guard page is marked non-readable, and that would transfer control to JVM's SEGV handler. This is part of JVM's mechanics to safepoint Java threads, e.g. for GC.
UPD: Hopefully, more details here.