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 I miss something? If it is where the best place for reporting? Thanks!
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.