On Thu, 30 Apr 2026 19:52:57 GMT, Vladimir Kozlov <[email protected]> wrote:
>>> I agree with using general NOPs as well.
>>
>> did you mean we should use single-byte nop when generating aot compiled code?
>
> @ashu-mehra. I looked on Loom post call nops and they use address nops
> without checking `UseAddressNop`:
>
> void MacroAssembler::post_call_nop() {
> if (!Continuations::enabled()) {
> return;
> }
> InstructionMark im(this);
> relocate(post_call_nop_Relocation::spec());
> InlineSkippedInstructionsCounter skipCounter(this);
> emit_int8((uint8_t)0x0f);
> emit_int8((uint8_t)0x1f);
> emit_int8((uint8_t)0x84);
> emit_int8((uint8_t)0x00);
> emit_int32(0x00);
> }
>
> which matches 8 bytes address not:
>
> 8: 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00
>
> So we may not be able to switch off `UseAddressNop` for AOT code.
> I checked and all 64-bit x86 processors seems supported this form. So I think
> we should be fine.
@vnkozlov there is also `Assembler::nop(uint i)` which can generate `i` bytes
of nop. It has different encoding when `i >= 12` for intel and amd.
// The rest coding is Intel specific - don't use consecutive address nops
// 12: 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 0x66 0x66 0x66 0x90
// 13: 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 0x66 0x66 0x66 0x90
// 14: 0x66 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 0x66 0x66 0x66 0x90
// 15: 0x66 0x66 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 0x66 0x66
0x66 0x90
vs
// The rest coding is AMD specific - use consecutive address nops
// 12: 0x66 0x0F 0x1F 0x44 0x00 0x00 0x66 0x0F 0x1F 0x44 0x00 0x00
// 13: 0x0F 0x1F 0x80 0x00 0x00 0x00 0x00 0x66 0x0F 0x1F 0x44 0x00 0x00
// 14: 0x0F 0x1F 0x80 0x00 0x00 0x00 0x00 0x0F 0x1F 0x80 0x00 0x00 0x00 0x00
// 15: 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 0x0F 0x1F 0x80 0x00 0x00
0x00 0x00
// 16: 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 0x0F 0x1F 0x84 0x00 0x00
0x00 0x00 0x00
// Size prefixes (0x66) are added for larger sizes
Is this something which can affect the compiled code?
-------------
PR Comment: https://git.openjdk.org/jdk/pull/30778#issuecomment-4356691893
