Request for comments, very slow compilation with super-overloaded methods

[Maurizio Cimadamore]

Thanks for the report (and the patch) - we will file a bug on this. I 
believe the solution for this is to maintain a fixed-size heap of 
candidate; this stuff is mostly there for generating better overload 
diagnostics; but in the case you have 255 candidates, I doubt you want 
to see them all ;-)

Maurizio

On 29/05/13 20:09, Adam Domurad wrote:
> Hi, 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.
>
> Happy hacking,
> -Adam
>