java - How can the offset for a JVM jump instruction be 32768? -
while writing answer question jvm byte code offsets, noticed in behavior of javac , resulting class files can not explain:
when compiling class this
class farjump { public static void main(string args[]) { call(0, 1); } public static void call(int x, int y) { if (x < y) { y++; y++; // ... (10921 times - code post here!) y++; y++; } system.out.println(y); } } then resulting byte code contain following if_icmpge instruction:
public static void call(int, int); code: 0: iload_0 1: iload_1 2: if_icmpge 32768 5: iinc 1, 1 8: iinc 1, 1 ... according documentation of jump instructions, offset (which 32768 in case) computed follows:
if comparison succeeds, unsigned branchbyte1 , branchbyte2 used construct signed 16-bit offset, offset calculated (branchbyte1 << 8) | branchbyte2.
so offset said signed 16 bit value. however, maximum value signed 16 bit value can hold 32767, , not 32768.
the resulting class file still seems valid, , can executed normally.
i had @ bytecode checking in openjdk, , seems (to me) valid due parentheses being misplaced:
int jump = (((signed char)(code[offset+1])) << 8) + code[offset+2]; it cast first byte signed char. then apply shift, , add second byte. have expected be
int jump = (((signed char)(code[offset+1]) << 8)) + code[offset+2]; or maybe even
int jump = (signed char)((code[offset+1]) << 8) + code[offset+2]); but i'm not familiar type promotions , possible compiler-specific caveats of shifting signed , unsigned types, i'm not sure whether there deeper meaning behind cast...
so jump offset of 32768 comply specification? , jump computation code in openjdk make sense in regard?
the argument if_icmpge offset, javap shows jump target absolute position. is, javap should show getstatic @ 32768: , not 32770: (i.e., 2 + 32768).
Comments
Post a Comment