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

[Ron Shapiro]

Also, this patch by Brad also seems to have a big improvement in
Types.union() (and passes jtreg):
http://cr.openjdk.java.net/~ronsh/8228675/webrev.02/

It's independent from the above ideas, but does reduce the amount of
union()-ing.



On Wed, Sep 4, 2019 at 3:05 PM Ron Shapiro <ronshapiro at google.com> wrote:

> Friendly ping. This is really hurting some of our builds. Maurizio, are
> you able to prepare a patch for us to look at?
>
> On Tue, Aug 13, 2019 at 8:12 AM Ron Shapiro <ronshapiro at google.com> wrote:
>
>> Aren't types recreated across rounds if there are any transitive error
>> types? That was at least my assumption.
>>
>> On Mon, Aug 12, 2019 at 5:50 PM Jan Lahoda <jan.lahoda at oracle.com> wrote:
>>
>>> I wonder if this will work with annotation processors? (As these may
>>> create new interfaces into the hierarchy.)
>>>
>>> Jan
>>>
>>> On 07. 08. 19 12:25, Ron Shapiro wrote:
>>> > Made the change for a WeakHashMap:
>>> > http://cr.openjdk.java.net/~ronsh/8228675/webrev.01/.
>>> >
>>> > Perhaps it would make better sense for this to be a field on
>>> ClassType?
>>> > That would avoid the need for managing a cache with weak keys.
>>> >
>>> > Do you have any guidance on how you approach tradeoffs in memory vs.
>>> speed?
>>> >
>>> > On Mon, Aug 5, 2019 at 7:25 PM Vicente Romero <
>>> vicente.romero at oracle.com
>>> > <mailto:vicente.romero at oracle.com>> wrote:
>>> >
>>> >     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/20190904/7ba4ebe1/attachment-0001.html>