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