RFR 8228675: Resolve.findMethod doesn't cache interface type calculation

Vicente Romero vicente.romero at oracle.com
Mon Aug 5 17:24:26 UTC 2019


not sure if we should add yet another cache to javac but in any case it 
should be implemented with a: WeakHashMap,

Thanks,
Vicente

On 8/5/19 10:32 AM, Ron Shapiro wrote:
> Fair question.
>
> github.com/google/dagger <http://github.com/google/dagger> generates 
> implementations of interfaces that implement a dependency injection 
> graph. Sometimes, though not always, these interfaces have dozens if 
> not hundreds of (super)interfaces which allow for builds to be 
> sharded: each subsection of the build refers to the superinterface and 
> then at the root of the build there is a union of them all. Naturally, 
> this means this must be rebuilt on most/all changes to any subproject 
> of the build.
>
> בתאריך יום ב׳, 5 באוג׳ 2019, 17:05, מאת Vicente Romero 
> ‏<vicente.romero at oracle.com <mailto:vicente.romero at oracle.com>>:
>
>     Hi Ron,
>
>     Just out of curiosity, what is the context in which this issue
>     arises? Naturally consuming more memory we can speed up javac but
>     this can lead to other problems too.
>
>     Thanks,
>     Vicente
>
>     On 8/5/19 8:24 AM, Ron Shapiro wrote:
>>     Friendly ping
>>
>>     בתאריך שבת, 27 ביולי 2019, 0:05, מאת Ron Shapiro
>>     ‏<ronshapiro at google.com <mailto:ronshapiro at google.com>>:
>>
>>         Hi,
>>
>>         Please review this change to speed up Resolve.findMethod for
>>         large classes that have large numbers of (super)interfaces
>>
>>         webrev: http://cr.openjdk.java.net/~ronsh/8228675/webrev.00/
>>         bug: https://bugs.openjdk.java.net/browse/JDK-8228675
>>
>>         Thanks,
>>         Ron
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190805/140916b8/attachment-0001.html>


More information about the compiler-dev mailing list