RFR: 8358535: Changes in ClassValue (JDK-8351996) caused a 1-9% regression in Renaissance-PageRank

[Chen Liang]

On Thu, 7 Aug 2025 19:29:53 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Also, this cache mechanism was authored before JDK 8 introduced fast table cache in `ConcurrentHashMap`. In the long run, we may switch the ClassValueMap to a ConcurrentHashMap-derived structure, like a `ReferencedKeyMap`.
>
> Ah, OK, so this is already slow path, good. But are we sure overwriting cache entry _with (the live version of) itself_ would not break things? Looking at `addToCache` implemenation, I am not 100% convinced it is safe. Please check?

This was the code on JDK 24 GA:
https://github.com/openjdk/jdk/blob/6705a9255d28f351950e7fbca9d05e73942a4e27/src/java.base/share/classes/java/lang/ClassValue.java#L458-L468

This fix is essentially the same as the previous. The cache entry + version is like a bloom filter: if it exists and the version is right, we can ensure we get the right item. A cache entry with an invalid version is essentially invalid, but it stays in the cache unless accessed by cache update requests. Yes I know this may constitute a resource leak, which is tracked by https://bugs.openjdk.org/browse/JDK-8352622.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26679#discussion_r2261386354