On Fri, 8 Jan 2021 11:06:17 GMT, Peter Levart <plev...@openjdk.org> wrote:
> So what do you think of this variant: I like it. I originally kept the fields volatile so that we don't observe stale values on `getForward`/`getReverse`, but you're right in that even if we do, the correct value will be observed when doing a volatile read in compute, at the additional expense of evaluating class loader relationships, but again, that's the slow path. IIUC, your changes mostly all flow from the decision to declare the fields as non-volatile; if they were still declared as volatile then it'd be impossible to observe null in them, I think (correct me if I'm wrong; it seems like you thought through this quite thoroughly) as then I don't see how could a volatile read happen before the initial volatile writes as the writes are part of the ClassValues constructor invocation and the reference to the ClassValues object is unavailable externally before the constructor completes. In any case, your approach definitely avoids any of these concerns so I'm inclined to go with it. ------------- PR: https://git.openjdk.java.net/jdk/pull/1918
