On Wed, 14 Jan 2026 20:14:40 GMT, Coleen Phillimore <[email protected]> wrote:
>> src/hotspot/share/oops/inlineKlass.hpp line 95: >> >>> 93: int _null_free_atomic_size_in_bytes; // size and alignment >>> requirement for a null-free atomic layout, -1 if no atomic flat layout is >>> possible >>> 94: int _nullable_atomic_size_in_bytes; // size and alignment >>> requirement for a nullable layout (always atomic), -1 if no nullable flat >>> layout is possible >>> 95: int _nullable_non_atomic_size_in_bytes; // size and alignment >>> requirement for a nullable non-atomic layout, -1 if not available >> >> Here is something that I'm confused about. Does an InlineKlass have >> multiple possible layouts and sizes depending on the container? Is that why >> the InlineKlass needs to save all these size non-static data members? > > Can you align the // s please? > Here is something that I'm confused about. Does an InlineKlass have multiple > possible layouts and sizes depending on the container? Is that why the > InlineKlass needs to save all these size non-static data members? An InlineKlass supports a set of layout according to its own characteristics (number of fields, atomicity, etc.). When computing the layout of a container with a value field, the JVM looks at the characteristics of the field (static, final , strict, null-free, etc.) and the layouts available for this InlineKlass and selects the best one that satisfies all requirements. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1407#discussion_r2698655768
