JDK-8007144 : Incremental inlining mistakes some call sites for dead ones and doesn't inline them
- Type: Bug
- Component: hotspot
- Sub-Component: compiler
- Affected Version: 8
- Priority: P4
- Status: Resolved
- Resolution: Fixed
- Submitted: 2013-01-30
- Updated: 2024-12-05
- Resolved: 2013-02-05
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 7 | JDK 8 | Other |
|---|---|---|
7u40Fixed  |
8Fixed |
hs24Fixed |
Related Reports
|
Relates :
|
Description
Before incremental inlining inlines a new call site, it sanity checks the input state of the call node: if the call is in a part of the graph that is dead, there's no need to proceed with inlining and, the parser doesn't expect a strange input state anyway. One the check consists in testing the input edges to the call node that correspond to input arguments for top. Long/double arguments to a call are in 2 halves, one of which is top so incremental inlining will skip all calls with at least a long or double argument, mistaken them for dead calls. This bug impacts the performance of the box2d test with nashorn (10-20% performance increase once fixed and LiveNodeCountInliningCutoff bumped to 30000).
Comments
|