[lworld] RFR: 8375441: [lworld] C2: assert(is_instance()) failed: bad cast [v2]

[Marc Chevalier]

On Wed, 4 Feb 2026 10:53:59 GMT, Quan Anh Mai <qamai at openjdk.org> 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