On Fri, 2 May 2025 15:17:25 GMT, Chen Liang <li...@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 incrementally with one additional
> commit since the last revision:
>
> Update src/java.base/share/classes/java/lang/ClassValue.java
>
> Co-authored-by: Shaojin Wen <shaojin.we...@alibaba-inc.com>
src/java.base/share/classes/java/lang/ClassValue.java line 463:
> 461: var updated = entry.refreshVersion(classValue.version);
> 462: if (updated != entry) {
> 463: put(classValue.identity, updated);
This appears to associate a value and contradicts the `readAccess` method name
and the comment on the method that says "A simple read access to this map".
Did I misunderstand what `readAccess` is meant in the context of `ClassValue`
semantics?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/24043#discussion_r2080052630
