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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]