On Fri, 21 Jan 2022 11:04:22 GMT, Aleksey Shipilev <sh...@openjdk.org> wrote:
>> JDK-8277072 introduced java.io.ClassCache, but there seem to be at least two >> issues with it: >> - The cache cannot disambiguate between cleared SoftReference and the >> accidental passing of `null` value; in that case, the retry loop would spin >> indefinitely; >> - If retry loop would spin several times, every time discovering a cleared >> SoftReference, it would create and register new SoftReference on the >> ReferenceQueue. However, it would not *drain* the RQ in the loop; in that >> case, we might have the unbounded garbage accumulating in RQ; >> >> Attention @rkennke, @plevart. >> >> Additional testing: >> - [x] Linux x86_64 fastdebug `java/io/ObjectStreamClass` >> - [x] Linux x86_64 fastdebug `tier1` >> - [x] Linux x86_64 fastdebug `tier2` >> - [x] Linux x86_64 fastdebug `tier3` > > Aleksey Shipilev has updated the pull request with a new target base due to a > merge or a rebase. The incremental webrev excludes the unrelated changes > brought in by the merge/rebase. The pull request contains seven additional > commits since the last revision: > > - Guarantee progress for at least one thread > - Merge branch 'master' into JDK-8280041-classcache-problems > - Test summary > - GC sanity test > - NullValueTest > - Merge branch 'master' into JDK-8280041-classcache-problems > - Fix This looks good, although I don't know whether the additional check for strongReferent != null is needed in clearStrong(). This is all racy code and you have already got a non-null return from getStrong() in case you are calling clearStrong()... ------------- Marked as reviewed by plevart (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7092
