JDK-8170594 : >>>=0 generates invalid bytecode for BaseNode LHS
- Type: Bug
- Component: core-libs
- Sub-Component: jdk.nashorn
- Affected Version: 8u112,9
- Priority: P2
- Status: Resolved
- Resolution: Fixed
- OS: generic
- CPU: generic
- Submitted: 2016-12-01
- Updated: 2017-11-29
- Resolved: 2016-12-01
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 8 | JDK 9 |
|---|---|
8u152Fixed  |
9 b148Fixed |
Description
The expression "a.b >>>=0" or "a[b] >>>=0" will leave a lingering "a" loaded on the operand stack when generating bytecode, in many cases throwing off stack maps and ultimately failing the verifier. This is specific to the >>>= operator, in case where the LHS is a base expression (property or element access) and the RHS is a literal zero. The bug is in a special-case handling of RHS zero (we have a special path for "coerce to UInt32, which is basically what >>>=0 is doing) that is not loading LHS with "base already on stack" flag set and thus resulting in an additional, unnecessary load of the base.
Comments
|