-
Enhancement
-
Resolution: Fixed
-
P4
-
9
-
b52
-
Not verified
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8085344 | emb-9 | Maurizio Cimadamore | P4 | Resolved | Fixed | team |
The current javac code type-checks unary/binary and other operators by using a restricted form of overload resolution. While this is a very general approach (and useful too in case of operator overloading), it's causing several issues:
* implementation is sub-optimal performance-wise, as an overload resolution is generally a slow process; most of the type-checking decision associated with operators can be made by looking up a value in a table. After the introduction of speculative attribution, the cost of doing operator overloading was so high that eventually we came up with a way to speed up those overload lookups, but we're still far from O(1) performances.
* It is hard to tell as to whether the implementation behaves according to the spec; as the spec describes the type-checking rules in a more tabular fashion, there is a significant gap between what the spec and javac does, which has been in the past source of issues (i.e. w.r.t. '==').
* Since tweaks are required to make overload resloution work in the case of operators, the resulting code is not that maintainable too - for instance, there are specific flags whose purpose is specifically to tweak the behavior of the most specific check during an operator lookup. All this is, needless to say, error prone.
It would be worthwhile to investigate as to whether the current type-checking code can be turned into something more deterministic and table-oriented; that would likely benefit both maintainability and compliance with the JLS.
* implementation is sub-optimal performance-wise, as an overload resolution is generally a slow process; most of the type-checking decision associated with operators can be made by looking up a value in a table. After the introduction of speculative attribution, the cost of doing operator overloading was so high that eventually we came up with a way to speed up those overload lookups, but we're still far from O(1) performances.
* It is hard to tell as to whether the implementation behaves according to the spec; as the spec describes the type-checking rules in a more tabular fashion, there is a significant gap between what the spec and javac does, which has been in the past source of issues (i.e. w.r.t. '==').
* Since tweaks are required to make overload resloution work in the case of operators, the resulting code is not that maintainable too - for instance, there are specific flags whose purpose is specifically to tweak the behavior of the most specific check during an operator lookup. All this is, needless to say, error prone.
It would be worthwhile to investigate as to whether the current type-checking code can be turned into something more deterministic and table-oriented; that would likely benefit both maintainability and compliance with the JLS.
- backported by
-
JDK-8085344 Investigate alternate strategy for type-checking operators
-
- Resolved
-
- relates to
-
JDK-8161304 javac, check uses of Symtab.predefClass in the compiler
-
- Closed
-
-
JDK-8082311 NPE when compiling expression with "^"
-
- Closed
-
-
JDK-8161383 javac is looking for operator symbols at the wrong place
-
- Closed
-
-
JDK-8161639 javac, duplicate keys are added to maps binaryOperators and unaryOperators at Operators
-
- Closed
-