RFR 8228675: Resolve.findMethod doesn't cache interface type calculation
Maurizio Cimadamore
maurizio.cimadamore at oracle.com
Wed Sep 4 14:20:44 UTC 2019
This patch seems like a low-hanging fruit - union was already returning
element in that order in case they were unrelated, so I agree the extra
test looks redundant.
Maurizio
On 04/09/2019 14:02, Ron Shapiro wrote:
> 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/
> <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
> <mailto: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
> <mailto: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 <mailto: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>
> > <mailto: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>
> <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>
> <mailto: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>
> <mailto: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/3d6c9aa7/attachment-0001.html>
More information about the compiler-dev
mailing list