On Wed, 4 Feb 2026 10:53:59 GMT, Quan Anh Mai <[email protected]> wrote:
>> I think the problem isn't here, but in `field_value`: in case we need a >> non-atomic field, we don't need to find the containing field and cache that. >> If the containing field turns out not to be atomic, we can simply get the >> leaf field directly, and cache that. For now, I've made an error to ask for >> a flat declared field in case it's non-atomic: one probably want/should (but >> at least can) query the leaf fields individually. > > What if we have something like this: > > @Stable > static final VeryLargeValueType[] ARRAY = new null-free-non-atomic > VeryLargeValyeType[100]; > > The program uses a non-atomic layout because it will not do racy accesses on > this array, but the compiler may, and what should we do in this case? > Probably just give up? I was writing an elaborate answer exploring different options, but I fear I'm not sure enough what the compiler must honor in such a case. Or rather what guarantees are still kept by non-atomicity. I think the surely simplest, and safe strategy is indeed not to do this fancy expansion if we are loading from a non atomic array. A simple `&& aryptr->is_atomic()` in `compile.cpp` would do that.nn ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1923#discussion_r2763795325
