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

[Adam Domurad]

On 05/30/2013 04:39 AM, Maurizio Cimadamore wrote:
> 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 ;-)

Thank you! Ah, yes that sounds reasonable. I suppose even if they could 
quickly be determined to not be equal because of parameter length, there 
would still exist some possibility with many same-name 
same-argument-count methods.

Out of curiousity though, I do wonder why a custom singly-linked list is 
used everywhere. Can anyone explain this design choice ? I don't see 
where they would help performance over standard eg ArrayList.

Thanks for filing the bug.

Happy hacking,
-Adam

>
> 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
>>
>