Strange behaviour in DeferredCompletionFailureHandler
jan.lahoda at oracle.com
Tue Nov 13 09:44:41 UTC 2018
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?
> 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
> 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:
> Please let me know how it works in your usecase.
> 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
> > 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
> > I've tried to investigate the problem by myself and found next
> > 1)
> > Map
> > 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)
> > 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
> > 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
> > view of compiler performance. And I don't understand what's the
> > of class2Flip map introduction. Could you clarify, help me, please?
> > Cheers,
> > Dmitrii Batkovich
More information about the compiler-dev