JDK-8131682 : C1 should use multibyte nops everywhere
- Type: Enhancement
- Component: hotspot
- Sub-Component: compiler
- Affected Version: 9
- Priority: P3
- Status: Resolved
- Resolution: Fixed
- CPU: x86
- Submitted: 2015-07-16
- Updated: 2015-09-10
- Resolved: 2015-08-13
The Version table provides details related to the release that this issue/RFE will be addressed.
Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.
To download the current JDK release, click here.
Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.
To download the current JDK release, click here.
| JDK 9 |
|---|
9 b79Fixed  |
Related Reports
|
Relates :
|
Description
Current C1 sometimes uses the single-byte nops, e.g. for aligning the call immediate:
0.14% 0.16% 0x00007efd65652ba0: nop
0.16% 0.10% 0x00007efd65652ba1: nop
0.09% 0.04% 0x00007efd65652ba2: nop
10.35% 10.32% 0x00007efd65652ba3: nop
0.14% 0.10% 0x00007efd65652ba4: nop
0.14% 0.17% 0x00007efd65652ba5: nop
0.13% 0.14% 0x00007efd65652ba6: nop
10.59% 5.78% 0x00007efd65652ba7: callq 0x00007efd65046160 ; ImmutableOopMap{[192]=Oop [176]=Oop [184]=Oop }
;*invokespecial sink
; {optimized virtual_call}
This is due to code patterns like:
while (offset++ % BytesPerWord != 0) {
__ nop();
}
...even though we have Assembler::nop(int i). We might need to revisit the C1 nop emits, and refactor them to use the nop(int i) method instead of looping.
A proof-of-concept patch shows ~20% improvements on targeted call benchmarks, even on modern Haswell CPU.
Comments
|