On Sun, 27 Apr 2025 04:50:37 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 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 12 additional commits since > the last revision: > > - Cannot test for recursion eagerly - add test case > - More spec, eager exception, finish with existing, thanks John > - Merge branch 'master' of https://github.com/openjdk/jdk into > fix/classvalue-compute-remove > - docs > - Remove the throwing behavior due to shallow reentrancy > - Merge branch 'master' of https://github.com/openjdk/jdk into > fix/classvalue-compute-remove > - Add more tests to avoid critical errors like the last one > - Major typo > - Use identity of thread, some optimizations for single thread case > - Merge branch 'master' of https://github.com/openjdk/jdk into > fix/classvalue-compute-remove > - ... and 2 more: https://git.openjdk.org/jdk/compare/b0b85ba9...edd19537 One thing I didn't note in the javadoc, but which might be significant, is that `computeValue` calls can be restarted for unpredictable reasons. I gave some of them in the javadoc, but not all. I did not document the possibility of crosstalk between <CV,C> pairs. Another pair <CV,C2> might do a remove and update the internal CV version. The purpose of htis is to flush the CV cache. But it also creates an interference with ongoing computation of `computeValue` for the original <CV,C> pair. Maybe we should treat such crosstalk as a bug. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24043#issuecomment-2833168973
