-
Bug
-
Resolution: Won't Fix
-
P3
-
9
There is an interesting code in sharedRuntime_x86_64:
// Test if the oopMark is an obvious stack pointer, i.e.,
// 1) (mark & 3) == 0, and
// 2) rsp <= mark < mark + os::pagesize()
// These 3 tests can be done by evaluating the following
// expression: ((mark - rsp) & (3 - os::vm_page_size())),
// assuming both stack pointer and pagesize have their
// least significant 2 bits clear.
// NOTE: the oopMark is in swap_reg %rax as the result of cmpxchg
__ subptr(swap_reg, rsp);
__ andptr(swap_reg, 3 - os::vm_page_size());
Notice it checks the & 3 in the mark word. sharedRuntime_x86_32 does the same. But, interp_masm_x86 does 64-bit and 32-bit thing differently:
const int zero_bits = LP64_ONLY(7) NOT_LP64(3);
// Test if the oopMark is an obvious stack pointer, i.e.,
// 1) (mark & zero_bits) == 0, and
// 2) rsp <= mark < mark + os::pagesize()
//
// These 3 tests can be done by evaluating the following
// expression: ((mark - rsp) & (zero_bits - os::vm_page_size())),
// assuming both stack pointer and pagesize have their
// least significant bits clear.
// NOTE: the oopMark is in swap_reg %rax as the result of cmpxchg
subptr(swap_reg, rsp);
andptr(swap_reg, zero_bits - os::vm_page_size());
It is hard to tell why we treat different bitnesses differently, and this was like this since revision 0 (Coleen had merged interp_masm_x86_{32,64} withJDK-8074717, not changing the block in question semantically).
But, since there is a disconnect between what sharedRuntime and interp_masm do on x86_64, this might be the source of cryptic bugs? Need someone with expertise in this code to look at it.
// Test if the oopMark is an obvious stack pointer, i.e.,
// 1) (mark & 3) == 0, and
// 2) rsp <= mark < mark + os::pagesize()
// These 3 tests can be done by evaluating the following
// expression: ((mark - rsp) & (3 - os::vm_page_size())),
// assuming both stack pointer and pagesize have their
// least significant 2 bits clear.
// NOTE: the oopMark is in swap_reg %rax as the result of cmpxchg
__ subptr(swap_reg, rsp);
__ andptr(swap_reg, 3 - os::vm_page_size());
Notice it checks the & 3 in the mark word. sharedRuntime_x86_32 does the same. But, interp_masm_x86 does 64-bit and 32-bit thing differently:
const int zero_bits = LP64_ONLY(7) NOT_LP64(3);
// Test if the oopMark is an obvious stack pointer, i.e.,
// 1) (mark & zero_bits) == 0, and
// 2) rsp <= mark < mark + os::pagesize()
//
// These 3 tests can be done by evaluating the following
// expression: ((mark - rsp) & (zero_bits - os::vm_page_size())),
// assuming both stack pointer and pagesize have their
// least significant bits clear.
// NOTE: the oopMark is in swap_reg %rax as the result of cmpxchg
subptr(swap_reg, rsp);
andptr(swap_reg, zero_bits - os::vm_page_size());
It is hard to tell why we treat different bitnesses differently, and this was like this since revision 0 (Coleen had merged interp_masm_x86_{32,64} with
But, since there is a disconnect between what sharedRuntime and interp_masm do on x86_64, this might be the source of cryptic bugs? Need someone with expertise in this code to look at it.