On Wed, 4 Feb 2026 10:38:24 GMT, Marc Chevalier <[email protected]> wrote:
>> src/hotspot/share/ci/ciInstance.cpp line 95:
>>
>>> 93: InlineLayoutInfo* layout_info =
>>> holder->inline_layout_info_adr(index);
>>> 94: InlineKlass* vk = layout_info->klass();
>>> 95: oop res = vk->read_payload_from_addr(obj, offset,
>>> layout_info->kind(), THREAD);
>>
>> It seems to imply that this access is required to be atomic, what if it is a
>> non-atomic field?
>
> 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?
-------------
PR Review Comment:
https://git.openjdk.org/valhalla/pull/1923#discussion_r2763396079