RFR: 8351996: Behavioral updates for ClassValue::remove [v5]
Chen Liang
liach at openjdk.org
Fri Mar 28 23:43:06 UTC 2025
On Fri, 21 Mar 2025 19:44:48 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 incrementally with one additional commit since the last revision:
>
> docs
There shouldn't be.
1. This just allocates a new promise for a single-threaded computation; the promise just holds a field unless there is racy computeValue, which is rare. Also, most of the access to ClassValue is going to find a present entry, so the computation is rare and the impact may be even smaller.
2. The Promise objects are always removed by the finally block in `getFromHashMap`, so there should not be retained memory.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/24043#issuecomment-2762861151
More information about the core-libs-dev
mailing list