RFR: 8351996: Behavioral updates for ClassValue::remove [v2]

[Jaikiran Pai]

On Wed, 19 Mar 2025 21:35:53 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The recent patch #23866 makes calling `ClassValue::remove()` from `ClassValue::computeValue()` end up in infinite loops while fixing the stale value risk from the method.
>> 
>> The proposed fix is to preserve the stale value risk fix, and update the remove-from-compute behavior from the original designated no-op behavior to throwing an exception, as the original behavior conflicts with the stale value fix.
>> 
>> The implementation track the owner thread in promises (accessed in locked section); as a result, we can fail-fast on recursive removals from `computeValue`. I did not choose to use `ThreadTracker` as it is designed for single tracker and multiple threads, while this case here sees often just one thread, and the threads outlive the promise objects.
>> 
>> Also updated the API specs for `remove` to more concisely describe the memory effects. Please review the associated CSR as well.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Use identity of thread, some optimizations for single thread case
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/classvalue-compute-remove
>  - Track threads on the promise for cheap reentrancy checks
>  - 8351996: Alternative way to ensure no stale values for ClassValue::remove

Hello Chen, not a review of the code, but the tier1 failures in the GitHub actions jobs look related:


java.lang.StackOverflowError: Recursive initialization of class value
	at java.base/java.lang.ClassValue$Entry.registerExtraThread(ClassValue.java:321)
	at java.base/java.lang.ClassValue$ClassValueMap.startEntry(ClassValue.java:481)
	at java.base/java.lang.ClassValue.getFromHashMap(ClassValue.java:196)
	at java.base/java.lang.ClassValue.getFromBackup(ClassValue.java:183)
	at java.base/java.lang.ClassValue.get(ClassValue.java:119)

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

PR Comment: https://git.openjdk.org/jdk/pull/24043#issuecomment-2743411188