RFR: JDK-8209055: c.s.t.javac.code.DeferredCompletionFailureHandler seems to use WeakHashMap incorrectly

Jan Lahoda jan.lahoda at oracle.com
Wed Oct 31 14:59:17 UTC 2018


After JDK-8187950, when a Symbol is completed in "user"/external mode 
(as opposed to "javac internal" mode), and the completion fails, the 
failed Symbol is "split", so that the user's code and javac may see a 
different version of the Symbol (e.g. completed/not completed). This 
helps to prevent throwing CompletionFailures to user's code.

But the issue is that ClassFinder.loadClass may create "speculative" 
ClassSymbols, which are subsequently removed if they turn out to be 
non-existent. But when this happens in the "user" mode (like inside 
Elements.getTypeElement), even these non-existent ClassSymbols are still 
retained, and the number of ClassSymbols retained this way may be fairly 
high. The proposed patch is to clear these speculative Symbols even from 
the "user" mode cache.

Bug: https://bugs.openjdk.java.net/browse/JDK-8209055
Webrev: http://cr.openjdk.java.net/~jlahoda/8209055/webrev.00/

Any feedback is welcome.


More information about the compiler-dev mailing list