JDK-8358535 : Changes in ClassValue (JDK-8351996) caused a 1-9% regression in Renaissance-PageRank
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang.invoke
  • Affected Version: 25
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2025-06-03
  • Updated: 2025-08-27
  • Resolved: 2025-08-09
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 25 JDK 26
25.0.2Fixed 26 b11Fixed
Related Reports
Causes :  
JDK-8351996 - Behavioral updates for ClassValue::remove
Sub Tasks
JDK-8365054 :  
Release Note: Performance Regression in java.lang.ClassValue::get - Resolved
Description
Changes in ClassValue (JDK-8351996) caused a performance regression in Renaissance-PageRank

Linux aarch64  -0.9%
Linux x64      -4.7%
MacOSX aarch64 -3.4%
Windows x64    -8.8%
Comments
[~chegar] Yes, your understanding is correct. The other scenarios that can trigger this include maybe hash collision, but I anticipate that to be extremely rare and can be largely ignored. remove is the only way to **consistently** reproduce this bug.
27-08-2025
As a point of clarification (since the release note is a little ambiguous). Code is only potentially affected by this issue if it uses `ClassValue::remove`, right? Specifically, use cases that only use `computeValue` and `get` - so a simple state transition: uninitialized to initialized - are unaffected. Correct?
27-08-2025
[jdk25u-fix-request] Approval Request from Chen Liang Clean backport, fixes regression too late for 25 GA or 25.0.1, verified on a manual backport to GA
10-08-2025
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk25u/pull/80 Date: 2025-08-09 23:56:11 +0000
10-08-2025
Changeset: e13b4c8d Branch: master Author: Chen Liang <liach@openjdk.org> Date: 2025-08-09 23:44:21 +0000 URL: https://git.openjdk.org/jdk/commit/e13b4c8de944ab14a1d12f6251e83f4fdd9e0198
09-08-2025
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/26679 Date: 2025-08-07 16:23:00 +0000
07-08-2025
Problem is ClassValue map's readAccess is missing a cache update - this missing update will cause the slow path to be repeatedly invoked when the an unrelated entry is deleted. The used cache entry has been invalidated but the cache refresh is missing due to the bug.
06-08-2025
Thanks for prompting this. Seems Scala is using ClassValueCompat, which hits a cache-missed path in ClassValue. Need to check if this is due to problem with caching mechanism in ClassValue.
02-08-2025
Is there any update on this regression?
01-08-2025
The cause might be that the patch now always checks for a cache update in the backing map upon a read access to the map. We can test this assumption first.
05-06-2025