Skip to content

Conversation

@1stub
Copy link
Collaborator

@1stub 1stub commented Jan 4, 2026

Object metadata is now in its own segment of a page where the layout looks like |page header|metadata|objects...|. Metadata fields have not been segregated yet, will be hitting that in a future PR.

@1stub 1stub requested a review from marron-at-work January 4, 2026 19:49
Copy link
Collaborator

@marron-at-work marron-at-work left a comment

Choose a reason for hiding this comment

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

Do we have any perf results for the impacts of moving the metadata? Also I assume this is part of migrating to the page-per-type allocator.

GC_REFCT_LOCK_RELEASE();
}

// Due to how we (currently) setup data and metadata offsets in our page this always fails!
Copy link
Collaborator

Choose a reason for hiding this comment

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

This comment and code are a bit confusing. Can you confirm that we safely check a reference is into the interior of the data segment (may be into the middle of an object though since we allow that for roots).

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Whoops! I forgot to delete that comment, it was referencing an issue with setting the pointer to the beginning of a pages data which I resolved.

I tested this code with nbody, raytracer, db, compiler op pass, and binary trees and did not encounter any issues with references to the interior of the data segment.

@1stub
Copy link
Collaborator Author

1stub commented Jan 4, 2026

For nbody, raytracer, db, and oppass I saw around a 20% decrease in collection pause time, but for binary trees I saw roughly a 30% increase :(. Not quite sure what is causing this, I will have to take a deeper look. And yes, this is part of migrating to the page-per-type allocator.

@1stub
Copy link
Collaborator Author

1stub commented Jan 5, 2026

I did a fair bit more digging today and realized the slowdown appears to be caused by the decs thread (sigh).

In binary trees the decs thread is working through massive amounts of decrements while the mutator thread runs, then when we return to collect it has generated thousands of pages who need to be rebuilt, leading to massive pauses.

So, it looks like I'll need to setup the decs thread to also be able to reprocess pages without affecting the mutator thread, then ill get back to this and get a better understanding of how moving the metadata actually affects perf.

@marron-at-work
Copy link
Collaborator

Can we do most of the rebuild work lazily -- specifically when a mutator thread gets a new page?

@1stub
Copy link
Collaborator Author

1stub commented Jan 5, 2026

I believe so. When the mutator thread gets a new page we should be able to check whether the page has objects that were decremented, and if so rebuild the page.

I'll take a look and see what that may look like and how perf is affected.

@1stub 1stub closed this Jan 15, 2026
@1stub 1stub deleted the 12_31_out_of_line_mdata branch January 15, 2026 15:01
@1stub 1stub restored the 12_31_out_of_line_mdata branch January 15, 2026 16:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants