JDK-8066669 : dust.js performance regression caused by primitive field conversion
- Type: Bug
- Component: core-libs
- Sub-Component: jdk.nashorn
- Priority: P3
- Status: Resolved
- Resolution: Fixed
- OS: generic
- CPU: generic
- Submitted: 2014-12-04
- Updated: 2015-06-04
- Resolved: 2014-12-11
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 |
|---|---|
8u40Fixed  |
9 b43Fixed |
Description
A performance regression with the dust.js templating library was reported on nashorn-dev: http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-November/003860.html While the original report focuses on 8u05 vs 8u25, there is even a bigger regression to 8u40. While the reasons for the 8u25 regression are not very clear, the 8u40 regression is caused by the switch to dual fields representation. The problem here is that the '$len' and '$idx' properties switch between int and Object type a lot, and since this is a get/setAttr access the property maps are not cached in the callsite. While it would not solve the deeper propblem with indexed access callsites, it seems we solve this particular case (and probably improve a lot of other code) by treating index nodes with string constant ids like regular property accesses.
Comments
|