Strange behaviour in DeferredCompletionFailureHandler

Jan Lahoda jan.lahoda at
Mon Nov 12 15:57:22 UTC 2018

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:

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 dagger
> dependency injection and with some javac task listener (You may see
> 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
> 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 field
> reassignment. Sure we need at least one TaskListener here.
> So, I've found that fix for
> 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

More information about the compiler-dev mailing list