RFR: 8351045: ClassValue::remove cannot ensure computation observes up-to-date state

[John R Rose]

On Mon, 3 Mar 2025 15:24:05 GMT, Chen Liang <liach at 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