[prev in list] [next in list] [prev in thread] [next in thread]
List: openjdk-compiler-dev
Subject: Re: RFR 8228675: Resolve.findMethod doesn't cache interface type calculation
From: Ron Shapiro <ronshapiro () google ! com>
Date: 2019-08-13 5:12:52
Message-ID: CACA6h9vzJ5QrcwRWPdL=k=5AMUJcFY2BXon=bVihZEpHM2f-XQ () mail ! gmail ! com
[Download RAW message or body]
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@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@oracle.com
> > <mailto:vicente.romero@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@oracle.com <mailto:vicente.romero@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@google.com <mailto:ronshapiro@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
> >>>
> >>
> >
>
[Attachment #3 (text/html)]
<div dir="ltr">Aren't types recreated across rounds if there are any transitive \
error types? That was at least my assumption.</div><br><div class="gmail_quote"><div \
dir="ltr" class="gmail_attr">On Mon, Aug 12, 2019 at 5:50 PM Jan Lahoda <<a \
href="mailto:jan.lahoda@oracle.com">jan.lahoda@oracle.com</a>> \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I wonder if this will \
work with annotation processors? (As these may <br> create new interfaces into the \
hierarchy.)<br> <br>
Jan<br>
<br>
On 07. 08. 19 12:25, Ron Shapiro wrote:<br>
> Made the change for a WeakHashMap: <br>
> <a href="http://cr.openjdk.java.net/~ronsh/8228675/webrev.01/" rel="noreferrer" \
target="_blank">http://cr.openjdk.java.net/~ronsh/8228675/webrev.01/</a>.<br> > \
<br> > Perhaps it would make better sense for this to be a field on ClassType? \
<br> > That would avoid the need for managing a cache with weak keys.<br>
> <br>
> Do you have any guidance on how you approach tradeoffs in memory vs. speed?<br>
> <br>
> On Mon, Aug 5, 2019 at 7:25 PM Vicente Romero <<a \
href="mailto:vicente.romero@oracle.com" target="_blank">vicente.romero@oracle.com</a> \
<br> > <mailto:<a href="mailto:vicente.romero@oracle.com" \
target="_blank">vicente.romero@oracle.com</a>>> wrote:<br> > <br>
> not sure if we should add yet another cache to javac but in any case<br>
> it should be implemented with a: WeakHashMap,<br>
> <br>
> Thanks,<br>
> Vicente<br>
> <br>
> On 8/5/19 10:32 AM, Ron Shapiro wrote:<br>
>> Fair question.<br>
>><br>
>> <a href="http://github.com/google/dagger" rel="noreferrer" \
target="_blank">github.com/google/dagger</a> <<a \
href="http://github.com/google/dagger" rel="noreferrer" \
target="_blank">http://github.com/google/dagger</a>><br> >> generates \
implementations of interfaces that implement a<br> >> dependency \
injection graph. Sometimes, though not always, these<br> >> interfaces \
have dozens if not hundreds of (super)interfaces which<br> >> allow for \
builds to be sharded: each subsection of the build<br> >> refers to the \
superinterface and then at the root of the build<br> >> there is a union \
of them all. Naturally, this means this must be<br> >> rebuilt on \
most/all changes to any subproject of the build.<br> >><br>
>> בתאריך יום ב׳, 5 באוג׳ 2019, 17:05, מאת Vicente \
Romero<br> >> <<a href="mailto:vicente.romero@oracle.com" \
target="_blank">vicente.romero@oracle.com</a> <mailto:<a \
href="mailto:vicente.romero@oracle.com" \
target="_blank">vicente.romero@oracle.com</a>>>:<br> >><br>
>> Hi Ron,<br>
>><br>
>> Just out of curiosity, what is the context in which this \
issue<br> >> arises? Naturally consuming more memory we can speed \
up javac<br> >> but this can lead to other problems too.<br>
>><br>
>> Thanks,<br>
>> Vicente<br>
>><br>
>> On 8/5/19 8:24 AM, Ron Shapiro wrote:<br>
>>> Friendly ping<br>
>>><br>
>>> בתאריך שבת, 27 ביולי 2019, 0:05, מאת Ron \
Shapiro<br> >>> <<a href="mailto:ronshapiro@google.com" \
target="_blank">ronshapiro@google.com</a> <mailto:<a \
href="mailto:ronshapiro@google.com" \
target="_blank">ronshapiro@google.com</a>>>:<br> >>><br>
>>> Hi,<br>
>>><br>
>>> Please review this change to speed up \
Resolve.findMethod<br> >>> for large classes that have \
large numbers of<br> >>> (super)interfaces<br>
>>><br>
>>> webrev: <a \
href="http://cr.openjdk.java.net/~ronsh/8228675/webrev.00/" rel="noreferrer" \
target="_blank">http://cr.openjdk.java.net/~ronsh/8228675/webrev.00/</a><br> \
>>> bug: <a \
href="https://bugs.openjdk.java.net/browse/JDK-8228675" rel="noreferrer" \
target="_blank">https://bugs.openjdk.java.net/browse/JDK-8228675</a><br> \
>>><br> >>> Thanks,<br>
>>> Ron<br>
>>><br>
>><br>
> <br>
</blockquote></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic