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

Jonathan Gibbons jonathan.gibbons at oracle.com
Wed Nov 7 21:34:39 UTC 2018

Jan,

You don't need to @build JavacTestingAbstractProcessor, since it is not used.

Otherwise OK.

-- Jon

On 10/31/18 7:59 AM, Jan Lahoda wrote:

Hi,

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. Thanks, Jan

More information about the compiler-dev mailing list