On Fri, 12 Jun 2026 19:06:42 GMT, Quan Anh Mai <[email protected]> wrote:
>> Maybe? I do not have time for this this week, but I can try next week. What
>> exactly are you having in mind? Putting down some feature flags when
>> Shenandoah is enabled?
>
> In `fieldLayoutBuilder.cpp`, we have this:
>
> if (UseNullableNonAtomicValueFlattening) {
> _nullable_non_atomic_layout_size_in_bytes = new_raw_size;
> _null_marker_offset = null_marker_offset;
> _null_free_non_atomic_layout_alignment = _payload_alignment;
> }
> if (UseNullableValueFlattening) {
> // For the nullable atomic layout, the size mut be compatible with the
> platform capabilities
> int nullable_atomic_size = round_up_power_of_2(new_raw_size);
> if (nullable_atomic_size <= (int)MAX_ATOMIC_OP_SIZE) {
> _nullable_atomic_layout_size_in_bytes = nullable_atomic_size;
> _null_marker_offset = null_marker_offset;
> }
> }
>
> I wonder if it is a good idea to insert a little bit of code here to disable
> these when `UseShenandoahGC` is `true` and the layout has oop. What do you
> think @fparain?
I now pushed a simpler kludge: like ZGC, Shenandoah can "rely" on the
implementation detail that the embedded oops are "only" the problem when we
have compressed oops. Otherwise the atomic payloads have at most one oop, which
are apparently handled okay. This is still a kludge, but it errs to make things
slower instead of losing atomicity.
-------------
PR Review Comment:
https://git.openjdk.org/valhalla/pull/1971#discussion_r3413226550
