> 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)
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 three additional commits since the last revision: - Improve docs - Merge branch 'master' of https://github.com/openjdk/jdk into fix/classvalue-remove - 8351045: ClassValue::remove cannot ensure computation observes up-to-date state ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23866/files - new: https://git.openjdk.org/jdk/pull/23866/files/eabc8b63..a11aff0e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23866&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23866&range=00-01 Stats: 9916 lines in 215 files changed: 6360 ins; 1787 del; 1769 mod Patch: https://git.openjdk.org/jdk/pull/23866.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23866/head:pull/23866 PR: https://git.openjdk.org/jdk/pull/23866
