-
Enhancement
-
Resolution: Fixed
-
P4
-
8-shenandoah, 11-shenandoah, 14, 15
-
b25
After JDK-8245464, we have this shape of cset check:
...65: mov %rax,%r10
...68: shr $0x17,%r10
...6c: mov $0x10000,%r11d
...72: cmpb $0x0,(%r11,%r10,1)
...77: je 0x00007f868c8ef355
But the immediate is very small, so there is no reason why it should take %r11. If we massage the code a bit with:
https://cr.openjdk.java.net/~shade/8245465/webrev.02/
...e5: mov %rax,%r10
...e8: shr $0x17,%r10
...ec: cmpb $0x0,0x10000(%r10)
...f4: je 0x00007f6be48f7ed5
Then we save the register there, and LRB midpath is also 3 bytes more compact.
...65: mov %rax,%r10
...68: shr $0x17,%r10
...6c: mov $0x10000,%r11d
...72: cmpb $0x0,(%r11,%r10,1)
...77: je 0x00007f868c8ef355
But the immediate is very small, so there is no reason why it should take %r11. If we massage the code a bit with:
https://cr.openjdk.java.net/~shade/8245465/webrev.02/
...e5: mov %rax,%r10
...e8: shr $0x17,%r10
...ec: cmpb $0x0,0x10000(%r10)
...f4: je 0x00007f6be48f7ed5
Then we save the register there, and LRB midpath is also 3 bytes more compact.
- is blocked by
-
JDK-8245464 Shenandoah: allocate collection set bitmap at lower addresses
- Resolved