Skip to content

Conversation

@niaow
Copy link
Member

@niaow niaow commented Dec 28, 2025

This simplifies the process of constructing and encoding layout bitmaps. Instead of creating big integers and merging them, we can create a pre-sized bitmap and set positions within it.

This also changes the encoding logic to allow larger layouts to be encoded inline. We would previously not encode a layout inline unless the size was less than the width of the data field. This is overly conservative.
A layout can be encoded inline as long as:

  1. The size fits within the size field.
  2. All set bits in the bitmap fit into the data field.

This simplifies the process of constructing and encoding layout bitmaps.
Instead of creating big integers and merging them, we can create a pre-sized bitmap and set positions within it.

This also changes the encoding logic to allow larger layouts to be encoded inline.
We would previously not encode a layout inline unless the size was less than the width of the data field.
This is overly conservative.
A layout can be encoded inline as long as:
1. The size fits within the size field.
2. All set bits in the bitmap fit into the data field.
@niaow niaow added the core label Jan 1, 2026
@niaow niaow requested a review from dgryski January 2, 2026 08:05
@dgryski
Copy link
Member

dgryski commented Jan 5, 2026

Are there any stdlib tests or hand-coded tests that exercise the new "larger layouts" logic?

@niaow
Copy link
Member Author

niaow commented Jan 6, 2026

I added a test to ensure that it is encoded correctly. We do not currently have a meaningful way to test the scanning logic.

@dgryski
Copy link
Member

dgryski commented Jan 6, 2026

Test corpus passes but I wouldn't mind having @aykevl take a second look.

Copy link
Member

@dgryski dgryski left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks correct but I don't have enough experience in this area to be confident.

// Create the global initializer.
bitmapBytes := make([]byte, int(objectSizeWords+7)/8)
bitmap.FillBytes(bitmapBytes)
reverseBytes(bitmapBytes) // big-endian to little-endian
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This big/little endian conversion doesn't seem to have an equivalent in the new code.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correct. The old getPointerBitmap code used big.Int which is stored in big-endian so the reverseBytes code was needed to fix it. buildPointerBitmap writes the bitmap normally so no endian logic is necessary,

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants