JDK-8134292 : Enable caching of eager pre-pass AST
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: jdk.nashorn
  • Affected Version: 10
  • Priority: P5
  • Status: Closed
  • Resolution: Future Project
  • OS: generic
  • CPU: generic
  • Submitted: 2015-08-24
  • Updated: 2017-07-05
  • Resolved: 2017-07-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.
Other
tbd_majorResolved
Related Reports
Relates :  
JDK-8133300 - Ensure symbol table immutability in Nashorn AST
Relates :  
JDK-8029952 - Parser doesn't scale well for large literals
Description
In JDK-8133300 we decided on not caching ASTs resulting from the compilation pre-pass. The main reason for this is a surprising difficulty of making it play nicely with apply-to-call (a2c) specialization (a2c generates specialized function signatures for a normally varargs-only function, so the resulting AST is inherently specific to the type specialization arity and thus non-cacheable). However, this results in inability to cache pre-pass ASTs in general (except for split functions), while that might still be desirable to further eliminate processing time.

Caching pre-pass non-split ASTs is desirable; in order to implement it we need to:
- make sure ApplySpecialization is rewritten so that it marks all transformation-subjected functions as non-cacheable
- make sure Symbol.useCount is recomputed when the function is cached
- make sure any other possible discrepancies between eager and on-demand compilation are smoothed over.
Comments
An alternative to caching eager pre-pass AST would be to make pre-pass parsing lazy as proposed in JDK-8059934. That would still require parsing source code twice, but the first pass would be much faster than our current pre-pass. Basically it would just check syntax and possibly extract some other information but avoid creating an AST.
19-11-2015