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

Jaikiran Pai jpai at openjdk.org
Thu May 8 16:05:04 UTC 2025


On Fri, 2 May 2025 15:17:25 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:
> 
>   Update src/java.base/share/classes/java/lang/ClassValue.java
>   
>   Co-authored-by: Shaojin Wen <shaojin.wensj at alibaba-inc.com>

src/java.base/share/classes/java/lang/ClassValue.java line 241:

> 239:                 } else {
> 240:                     throw ex instanceof Error err ? err : new Error(ex);
> 241:                 }

Hello Chen, i think this if/else for exception type checks can instead just be replaced with an unconditional `throw ex`;

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24043#discussion_r2080019642


More information about the core-libs-dev mailing list