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} with JDK-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.