RFR: 8280041: Retry loop issues in java.io.ClassCache [v3]

[Peter Levart]

On Wed, 19 Jan 2022 08:25:55 GMT, Aleksey Shipilev <shade at 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