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

Vicente Romero vicente.romero at oracle.com
Thu Nov 8 00:37:00 UTC 2018

I'm OK with the patch,

Thanks, Vicente

On 10/31/18 10: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