On Mon, 3 Mar 2025 15:24:05 GMT, Chen Liang <li...@openjdk.org> wrote:
> After a call to `ClassValue.remove`, a `ClassValue` can still install a value > that is computed with information that is not up-to-date with the remove > call. This is demonstrated in the test case, where an innocuous > `ClassValue.get` call on an uncomputed CV may happen to compute during which > a remove happened, and proceed to install an outdated value onto a CV. > > The fix is simple - to force computation to retry when a remove has happened, > so the retry can observe the up-to-date states from the remove. (finishEntry > and removeEntry are both synchronized on the object monitor of the > ClassValueMap instance) This pull request has now been integrated. Changeset: e71f3274 Author: Chen Liang <li...@openjdk.org> URL: https://git.openjdk.org/jdk/commit/e71f3274a9de4006bc8cdfe4ba1bd12a8867a11a Stats: 81 lines in 2 files changed: 61 ins; 3 del; 17 mod 8351045: ClassValue::remove cannot ensure computation observes up-to-date state Reviewed-by: rriggs, jrose ------------- PR: https://git.openjdk.org/jdk/pull/23866
