On Wed, 17 Apr 2024 15:17:52 GMT, Per Minborg <pminb...@openjdk.org> wrote:
>> Also, I want to mention a few important differences between `@Stable` and >> Stable Values: >> >> Patterns: >> 1. Benign race (does not exist in StableValue API): multiple threads can >> create an instance and upload, any non-null instance is functionally >> equivalent so race is ok (seen in most of JDK) >> 2. compareAndSet (setIfUnset): multiple threads can create instance, only >> one will succeed in uploading; usually for when the instance computation is >> cheap but we want single witness. >> 3. atomic computation (computeIfUnset): only one thread can create instance >> which will be witnessed by other threads; this pattern ensures correctness >> and prevents wasteful computation by other threads at the cost of locking >> and lambda creation. >> >> Allocation in objects: `@Stable` field is local to an object but >> `StableValue` is another object; thus sharing strategy may differ, as stable >> fields are copied over but StableValue uses a shared cache (which is even >> better for avoiding redundant computation) >> >> Question: >> 1. Will we ever try to expose the stable benign race model to users? >> 2. Will we ever try to inline the stable values in object layout like a >> stable field? > >> Question: >> >> 1. Will we ever try to expose the stable benign race model to users? >> 2. Will we ever try to inline the stable values in object layout like a >> stable field? > > 1. I think there is little or no upside in exposing the benign race. It would > also be difficult to assert the invariant, competing objects are functionally > equivalent. So, I think no. > > 2. In a static context, the stable value will be inlined (or rather > constant-folded). So we are partly already there. For pure instance contexts, > I have some ideas about this but it is non-trivial. > @minborg Just curious, why are you adding holder-in-holder benchmark cases? I'd like to test the transitive constant folding capabilities. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18794#issuecomment-2075119450
