sjvanrossum commented on PR #34764: URL: https://github.com/apache/beam/pull/34764#issuecomment-2841577401
@kennknowles the default object layout on recent JVMs (64 bit, 8 bytes alignment, 12 bytes object header, compressed references and class pointers) leaves 4 bytes of padding in `SimpleWindowedValue`: ``` org.apache.beam.sdk.util.WindowedValue$SimpleWindowedValue object internals: OFF SZ TYPE DESCRIPTION VALUE 0 8 (object header: mark) N/A 8 4 (object header: class) N/A 12 4 java.lang.Object SimpleWindowedValue.value N/A 16 4 org.apache.beam.sdk.transforms.windowing.PaneInfo SimpleWindowedValue.pane N/A 20 4 (object alignment gap) Instance size: 24 bytes Space losses: 0 bytes internal + 4 bytes external = 4 bytes total ``` `MinTimestampWindowedValue` and `TimestampedValueInGlobalWindow` also have the same size, but `TimestampedValueInGlobalWindow` packs the `timestamp` field in the alignment gap. ``` org.apache.beam.sdk.util.WindowedValue$MinTimestampWindowedValue object internals: OFF SZ TYPE DESCRIPTION VALUE 0 8 (object header: mark) N/A 8 4 (object header: class) N/A 12 4 java.lang.Object SimpleWindowedValue.value N/A 16 4 org.apache.beam.sdk.transforms.windowing.PaneInfo SimpleWindowedValue.pane N/A 20 4 (object alignment gap) Instance size: 24 bytes Space losses: 0 bytes internal + 4 bytes external = 4 bytes total org.apache.beam.sdk.util.WindowedValue$TimestampedValueInGlobalWindow object internals: OFF SZ TYPE DESCRIPTION VALUE 0 8 (object header: mark) N/A 8 4 (object header: class) N/A 12 4 java.lang.Object SimpleWindowedValue.value N/A 16 4 org.apache.beam.sdk.transforms.windowing.PaneInfo SimpleWindowedValue.pane N/A 20 4 org.joda.time.Instant TimestampedWindowedValue.timestamp N/A Instance size: 24 bytes Space losses: 0 bytes internal + 0 bytes external = 0 bytes total ``` And for `TimestampedValueInSingleWindow` and `TimestampedValueInMultipleWindows` it spills over into the next word (`timestamp` fills the alignment gap, `window`/`windows` spills into the next word): ``` org.apache.beam.sdk.util.WindowedValue$TimestampedValueInSingleWindow object internals: OFF SZ TYPE DESCRIPTION VALUE 0 8 (object header: mark) N/A 8 4 (object header: class) N/A 12 4 java.lang.Object SimpleWindowedValue.value N/A 16 4 org.apache.beam.sdk.transforms.windowing.PaneInfo SimpleWindowedValue.pane N/A 20 4 org.joda.time.Instant TimestampedWindowedValue.timestamp N/A 24 4 org.apache.beam.sdk.transforms.windowing.BoundedWindow TimestampedValueInSingleWindow.window N/A 28 4 (object alignment gap) Instance size: 32 bytes Space losses: 0 bytes internal + 4 bytes external = 4 bytes total org.apache.beam.sdk.util.WindowedValue$TimestampedValueInMultipleWindows object internals: OFF SZ TYPE DESCRIPTION VALUE 0 8 (object header: mark) N/A 8 4 (object header: class) N/A 12 4 java.lang.Object SimpleWindowedValue.value N/A 16 4 org.apache.beam.sdk.transforms.windowing.PaneInfo SimpleWindowedValue.pane N/A 20 4 org.joda.time.Instant TimestampedWindowedValue.timestamp N/A 24 4 java.util.Collection TimestampedValueInMultipleWindows.windows N/A 28 4 (object alignment gap) Instance size: 32 bytes Space losses: 0 bytes internal + 4 bytes external = 4 bytes total ``` With default object layout settings the addition of an `extensions` field would only increase the size of `TimestampedValueInGlobalWindow` by 8 bytes since it would spill into the next word, all the other subclasses should pack that field into the alignment gap. I'm not sure whether users of Beam commonly disable `UseCompressedPointers` or `UseCompressedOops`, but it would seem somewhat unlikely in my opinion since both of them would generally increase memory usage. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: github-unsubscr...@beam.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org