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) Test is good also. src/java.base/share/classes/java/lang/ClassValue.java line 504: > 502: Entry<?> e = remove(classValue.identity); > 503: // e == null: Uninitialized, and no pending calls to > computeValue. > 504: // remove didn't change anything. No change. Please capitalize the sentence: "Remove didn't…" Also "Remove and discard" instead of "remove discarded". Perhaps (this is being very picky) "Inside finishEntry, the logic will retry when it discovers the promise is removed." This is a good bug fix. Thanks for finding it. ------------- Marked as reviewed by jrose (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23866#pullrequestreview-2658737905 PR Review Comment: https://git.openjdk.org/jdk/pull/23866#discussion_r1980091146
