On Thu, 7 Aug 2025 19:29:53 GMT, Aleksey Shipilev <sh...@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
