Strange behaviour in DeferredCompletionFailureHandler

[Dmitry Batkovich]

Thank you, the patch from JDK-8209055 fixes my case. Could you please
backport it to JDK 11?

On Tue, Nov 13, 2018 at 12:44 PM Jan Lahoda <jan.lahoda at oracle.com> wrote:

> On 13.11.2018 10:29, Dmitry Batkovich wrote:
> > ok, but what's about WeakHashMap? I've lots of stale keys which should
> > be collected but they are not because they had strong references in
> values.
>
> There is no WeakHashMap after JDK-8209055. The idea is that "real"
> ClassSymbols are permanent anyway (held from Symtab) and "hypothetical"
> ClassSymbols are removed from the DeferredCompletionFailureHandler when
> they are removed from the Symtab.
>
> Does the patch fix your usecase?
>
> Thanks,
>      Jan
>
> >
> > On Mon, Nov 12, 2018 at 6:57 PM Jan Lahoda <jan.lahoda at oracle.com
> > <mailto:jan.lahoda at oracle.com>> wrote:
> >
> >     Hi Dmitry,
> >
> >     The overall goal is to avoid CompletionFailures to be thrown to the
> >     user
> >     code. This requires to "spit" a Symbol into user code version and an
> >     javac internal version and to use the user-code version while in user
> >     code, and javac internal version while in javac. (Because javac needs
> >     the CompletionFailures for correctness.)
> >
> >     There was an issue that even "hypothetical" Symbol were kept in the
> >     maps, which should be fixed now. Please see:
> >     https://bugs.openjdk.java.net/browse/JDK-8209055
> >
> >     Please let me know how it works in your usecase.
> >
> >     Thanks,
> >           Jan
> >
> >     On 12.11.2018 16:10, Dmitry Batkovich wrote:
> >      > Hi all,
> >      >
> >      > I've faced with javac 11 performance problem
> >      > in DeferredCompletionFailureHandler. I have a project with google
> >     dagger
> >      > dependency injection and with some javac task listener (You may
> see
> >      > https://youtrack.jetbrains.com/issue/IDEA-201978). In this case
> I see
> >      > lots FlipSymbolDescription#flip() traces in compiler profile
> >     snapshot.
> >      > I've tried to investigate the problem by myself and found next
> >     things:
> >      >
> >      > 1)
> >      > Map
> >
>  com.sun.tools.javac.code.DeferredCompletionFailureHandler.Handler#class2Flip
> >      > produces memory leaks because keys of the map are present as a
> >     part of
> >      > value object. So, keys are always strongly referenced. And usage
> of
> >      > WeakHashMap is useless here.
> >      >
> >      > 2)
> >
>  com.sun.tools.javac.code.DeferredCompletionFailureHandler.Handler#class2Flip
> >      > does nothing. Any information inside FlipSymbolDescription is
> >     never used
> >      > (DefferedCompleter is never used).
> >      >
> >      > 3) Handler.install/uninstall method usages (see setHandler()
> >     usages in
> >      > MultiTaskListener) produces lots of odd cycles where we have only
> >     field
> >      > reassignment. Sure we need at least one TaskListener here.
> >      >
> >      > So, I've found that fix for
> >      > https://bugs.openjdk.java.net/browse/JDK-8187950 is very dirty in
> >     point
> >      > view of compiler performance. And I don't understand what's the
> >     purpose
> >      > of class2Flip map introduction. Could you clarify, help me,
> please?
> >      >
> >      > Cheers,
> >      > Dmitrii Batkovich
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20181113/ec62445b/attachment-0001.html>