-
Bug
-
Resolution: Fixed
-
P4
-
repo-lilliput
-
x86, x86_64, aarch64
-
generic
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8303771 | Roman Kennke | P4 | Resolved | Fixed |
Currently we get the asymmetric locking check in the interpreters wrong:
ldr(header_reg, Address(rthread, JavaThread::lock_stack_current_offset()));
cmpoop(header_reg, obj_reg);
br(Assembler::NE, slow_case);
The intention is to load the top of the lock-stack, and compare it to the unlocked object, and, if not equal, branch to the slow-path to handle it. However, what it really does is, it loads the *address* of the top of lock-stack, and compares that to the unlocked object. This can never succeed, and therefore we always call the slow-path. Additionally, the address is not the address of the topmost object, it is the address of the next free slot. What we really want to load is the element at -1 oop from that address. This is not incorrect, but it's unnecessarily slow.
ldr(header_reg, Address(rthread, JavaThread::lock_stack_current_offset()));
cmpoop(header_reg, obj_reg);
br(Assembler::NE, slow_case);
The intention is to load the top of the lock-stack, and compare it to the unlocked object, and, if not equal, branch to the slow-path to handle it. However, what it really does is, it loads the *address* of the top of lock-stack, and compares that to the unlocked object. This can never succeed, and therefore we always call the slow-path. Additionally, the address is not the address of the topmost object, it is the address of the next free slot. What we really want to load is the element at -1 oop from that address. This is not incorrect, but it's unnecessarily slow.
- backported by
-
JDK-8303771 [Lilliput/JDK17] Fix interpreter asymmetric fast-locking
- Resolved