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

Reply via email to