JDK-8044502 : Get rid of global optimistic flag
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: jdk.nashorn
  • Affected Version: 8u40
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2014-06-02
  • Updated: 2015-01-21
  • Resolved: 2014-06-04
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.
8u40Fixed 9 b17Fixed
Currently, optimistic compilation is governed with the system property "nashorn.optimistic". It should be a command line option (e.g. --optimistic-types) configurable on a per-script-environment basis.

As part of this, tests currently relying on the optimistic flag (NumberAccessTest and NumberBoxingTest) should be relaxed to work identically with optimistic and non-optimistic compilation.
Another consequence of this commit is that we used to use the global optimistic flag to turn compilation of function variants specialized for parameter types on or off. This practically meant that without optimistic typing, we also didn't do function specialization. This will change: Nashorn's engine is perfectly capable of compiling type specialized functions on demand, so this will now happen even with optimistic compilation turned off. Coupled with lazy compilation, this means that even without optimistic, we only compile type variants of functions that are actually used. Granted, with optimistic off, we'll mostly end up generating functions that take all Object parameters, but e.g. a f(a*b) would still create a f(double) specialization. Also note that local variable type inference is also independent of optimistic compilation, so the benefit of type specialization even in absence of optimistic typing can be significant as it makes local type inference have effect across function call boundaries.

As part of this issue, we'll also set the default of --lazy-compilation to true.