On Wed, 19 Jan 2022 08:25:55 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 incrementally with one > additional commit since the last revision: > > Test summary So, this patch is fine for making ClassCache more robust as a re-usable component inside JDK (checking for non-null return of computeValue). The 2nd change, that apparently shields against unbounded accumulation of garbage, might not be enough in the sense that when garbage accumulated without bounds, there would be not progress. So before the patch, we would at least get an OOME and the loop would end. Now the loop could spin indefinitely. So perhaps we must rather prevent this from happening in some other way... I have an idea. Stay tuned. ------------- PR: https://git.openjdk.java.net/jdk/pull/7092
