-
Notifications
You must be signed in to change notification settings - Fork 11
Out-of-band Meta Data #425
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
marron-at-work
left a comment
There was a problem hiding this 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! |
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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.
|
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. |
|
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. |
|
Can we do most of the rebuild work lazily -- specifically when a mutator thread gets a new page? |
|
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. |
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.