-
Enhancement
-
Resolution: Fixed
-
P4
-
8-shenandoah, 11-shenandoah, 14, 15
-
b25
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8362758 | repo-phoenix | Daniel Daugherty | P4 | Resolved | Fixed | master |
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.
- backported by
-
JDK-8362758 Shenandoah: allocate collection set bitmap at lower addresses
-
- Resolved
-
- 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
-