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

[Chen Liang]

On Fri, 21 Mar 2025 13:44:17 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> 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)

@jaikiran Since you have looked at this patch and used CountDownLatch frequently before, I wonder if you would like to review the use of concurrency utilities in this patch.

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

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