Skip to content
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

Opportunity for performance improvement in CC #148

Closed
shwestrick opened this issue Mar 8, 2022 · 3 comments
Closed

Opportunity for performance improvement in CC #148

shwestrick opened this issue Mar 8, 2022 · 3 comments

Comments

@shwestrick
Copy link
Collaborator

shwestrick commented Mar 8, 2022

See #147 (comment)

@shwestrick
Copy link
Collaborator Author

shwestrick commented Mar 8, 2022

Essentially, the CC work list has a (typically small) space penalty because it does not exactly match DFS space behavior. The work list is a collection of objptrs that need to be traced, but this means that for large objects, we pay O(# fields) space to enqueue all of its fields.

Suggested fix: allow for CC work list entries of the form (objptr, field offset) so that we can complete a full DFS on one field of a large object while only paying O(1) space to remember how much of the object remains to be traced.

@shwestrick
Copy link
Collaborator Author

Another small optimization we could do is ensure that the mark/unmark loop happens as frequently as possible. So rather than enqueuing the full root set, we could enqueue one root,
do the tracing loop, then enqueue the next root, etc.

For example, in the code, we could add markLoop(...) to the end of forceForward, and unmarkLoop(...) to the end of forceUnmark

@shwestrick
Copy link
Collaborator Author

This is implemented by #150 💪

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

No branches or pull requests

1 participant