-
Bug
-
Resolution: Fixed
-
P3
-
7u40
-
b32
-
Verified
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8019742 | 7u60 | Vicente Arturo Romero Zaldivar | P3 | Resolved | Fixed | b01 |
JDK-8019909 | 7u45 | Vicente Arturo Romero Zaldivar | P3 | Closed | Fixed | b02 |
See attached sources.zip containing ArrayUtil.java & MethodHandle.java, taken from Groovy sourcecode.
They exhibit a case with which javac performs very badly.
Try
javac ArrayUtil.java #Not too bad
javac MethodHandle.java # But this takes many minutes
Note that MethodHandle references ArrayUtil, and this is auto-generated code.
ECJ compiles this source code in ~4 seconds.
This problem is present in JDK8 and JDK7.
- The performance problem stems from com.sun.tools.javac.comp.Resolve.InapplicableSymbolsError.Candidate#equals. This is used during method resolution, and is performed O(n^2) times for 'n' same-name methods. It references rather expensive methods that iterate over and potentially copy (eg for erasure) both argument lists, which can be up to 255 elements in this case.
- MethodHandle references a method from ArrayUtil that has 255 candidates; this is many orders of magnitude slower than it should be.
I have attached a patch that does a hackish fix, by providing a fast route for when method is obviously not a sub-signature of another.
The patch is mainly there as a proof-of-concept (its rather slapped on), hopefully someone knows a better way to fix these corner cases?
I am rather dubious about argument lists pervasively being treated as singly-linked lists. It makes certain operations quite costly, even changing the complexity of them unfavourably.
They exhibit a case with which javac performs very badly.
Try
javac ArrayUtil.java #Not too bad
javac MethodHandle.java # But this takes many minutes
Note that MethodHandle references ArrayUtil, and this is auto-generated code.
ECJ compiles this source code in ~4 seconds.
This problem is present in JDK8 and JDK7.
- The performance problem stems from com.sun.tools.javac.comp.Resolve.InapplicableSymbolsError.Candidate#equals. This is used during method resolution, and is performed O(n^2) times for 'n' same-name methods. It references rather expensive methods that iterate over and potentially copy (eg for erasure) both argument lists, which can be up to 255 elements in this case.
- MethodHandle references a method from ArrayUtil that has 255 candidates; this is many orders of magnitude slower than it should be.
I have attached a patch that does a hackish fix, by providing a fast route for when method is obviously not a sub-signature of another.
The patch is mainly there as a proof-of-concept (its rather slapped on), hopefully someone knows a better way to fix these corner cases?
I am rather dubious about argument lists pervasively being treated as singly-linked lists. It makes certain operations quite costly, even changing the complexity of them unfavourably.
- backported by
-
JDK-8019742 overload resolution: performance regression in JDK 7
-
- Resolved
-
-
JDK-8019909 overload resolution: performance regression in JDK 7
-
- Closed
-