-
Enhancement
-
Resolution: Fixed
-
P4
-
8-shenandoah, 11-shenandoah, 14, 15
-
b25
LRB midpath has the in-cset check that tests the address against cset bitmap. The default address for that bitmap is quite huge, so we end up emitting a large address immediate for it:
...65: mov %rax,%r10
...68: shr $0x17,%r10
...6c: movabs $0x7f3c5533d000,%r11
...76: cmpb $0x0,(%r11,%r10,1)
...7b: je 0x00007f3c408f4e55
We can help it if we put cset bitmap at lower addresses.
For example with:
https://cr.openjdk.java.net/~shade/8245464/webrev.01/
...65: mov %rax,%r10
...68: shr $0x17,%r10
...6c: mov $0x10000,%r11d
...72: cmpb $0x0,(%r11,%r10,1)
...77: je 0x00007f868c8ef355
Immediate used to take 10 bytes, now it takes 6 bytes.
...65: mov %rax,%r10
...68: shr $0x17,%r10
...6c: movabs $0x7f3c5533d000,%r11
...76: cmpb $0x0,(%r11,%r10,1)
...7b: je 0x00007f3c408f4e55
We can help it if we put cset bitmap at lower addresses.
For example with:
https://cr.openjdk.java.net/~shade/8245464/webrev.01/
...65: mov %rax,%r10
...68: shr $0x17,%r10
...6c: mov $0x10000,%r11d
...72: cmpb $0x0,(%r11,%r10,1)
...77: je 0x00007f868c8ef355
Immediate used to take 10 bytes, now it takes 6 bytes.
- blocks
-
JDK-8245465 Shenandoah: test_in_cset can use more efficient encoding
- Resolved
- relates to
-
JDK-8245773 Shenandoah: Windows assertion failure after JDK-8245464
- Closed