Hazard Pointer Reclamation - Unlock Tagged list faster #2106
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
This pull request was exported from Phabricator. Differential Revision: D51638674 |
|
This pull request was exported from Phabricator. Differential Revision: D51638674 |
instw
force-pushed
the
export-D51638674
branch
from
18a1822
to
30615d5
Compare
instw
pushed a commit
to instw/folly
that referenced
this pull request
Jan 22, 2024
Summary: PROBLEM During reclamation of tagged objects, we obtain a lock within the hazard pointer domain's tagged list. This list supports always pushing objects, but only allows popping when there is a lock (for `tagged_`). There is opportunity to improve the performance of reclamation, by keeping the `tagged_` list locked for a smaller amount of time. SOLUTION The list is locked to prevent multiple threads from reclaiming the same objects. During reclamation, we take all objects that are potentially cleaned up, and divide them into 2 parts: Those that must be reclaimed, and those that must not. The ones that are not are pushed back to the `tagged_` list, and the list is unlocked. The objects to be reclaimed are freed - by pushing to the cohort. The locking of list is to guard against the `tagged_` list itself, and hence when we push the not-to-be-reclaimed elements back, we could theoretically release the lock without waiting for the reclaimed objects to finish being processed. Also validated that the `nomatch` handling is thread-safe - The cohort's `push_safe_obj` uses as CAS loop to safely add to the top of the list. Would multiple copies of an object be pushed into a cohort? No - An object is either in the retirement list (i.e. list) in the cohort, or it's been processed for reclamation. This guarantee already exists (the diff doesn't change that). This means the only way multiple copies of an object can be pushed back to the safe list is if we end up clearing the `tagged_` list within the domain - which is the synchronization / shared memory point. Since we do dequeue and enqueue of that list under a lock, an object should would never appear on that list. The only (shared object) change is around addition to the cohort's safe list, which is meant to be thread-safe. Reviewed By: yfeldblum Differential Revision: D51638674
|
This pull request was exported from Phabricator. Differential Revision: D51638674 |
1 similar comment
|
This pull request was exported from Phabricator. Differential Revision: D51638674 |
instw
pushed a commit
to instw/folly
that referenced
this pull request
Jan 23, 2024
Summary: PROBLEM During reclamation of tagged objects, we obtain a lock within the hazard pointer domain's tagged list. This list supports always pushing objects, but only allows popping when there is a lock (for `tagged_`). There is opportunity to improve the performance of reclamation, by keeping the `tagged_` list locked for a smaller amount of time. SOLUTION The list is locked to prevent multiple threads from reclaiming the same objects. During reclamation, we take all objects that are potentially cleaned up, and divide them into 2 parts: Those that must be reclaimed, and those that must not. The ones that are not are pushed back to the `tagged_` list, and the list is unlocked. The objects to be reclaimed are freed - by pushing to the cohort. The locking of list is to guard against the `tagged_` list itself, and hence when we push the not-to-be-reclaimed elements back, we could theoretically release the lock without waiting for the reclaimed objects to finish being processed. Also validated that the `nomatch` handling is thread-safe - The cohort's `push_safe_obj` uses as CAS loop to safely add to the top of the list. Would multiple copies of an object be pushed into a cohort? No - An object is either in the retirement list (i.e. list) in the cohort, or it's been processed for reclamation. This guarantee already exists (the diff doesn't change that). This means the only way multiple copies of an object can be pushed back to the safe list is if we end up clearing the `tagged_` list within the domain - which is the synchronization / shared memory point. Since we do dequeue and enqueue of that list under a lock, an object should would never appear on that list. The only (shared object) change is around addition to the cohort's safe list, which is meant to be thread-safe. Reviewed By: yfeldblum Differential Revision: D51638674
instw
force-pushed
the
export-D51638674
branch
from
30615d5
to
f80275e
Compare
|
This pull request was exported from Phabricator. Differential Revision: D51638674 |
Summary: Pull Request resolved: facebook#2106 PROBLEM During reclamation of tagged objects, we obtain a lock within the hazard pointer domain's tagged list. This list supports always pushing objects, but only allows popping when there is a lock (for `tagged_`). There is opportunity to improve the performance of reclamation, by keeping the `tagged_` list locked for a smaller amount of time. SOLUTION The list is locked to prevent multiple threads from reclaiming the same objects. During reclamation, we take all objects that are potentially cleaned up, and divide them into 2 parts: Those that must be reclaimed, and those that must not. The ones that are not are pushed back to the `tagged_` list, and the list is unlocked. The objects to be reclaimed are freed - by pushing to the cohort. The locking of list is to guard against the `tagged_` list itself, and hence when we push the not-to-be-reclaimed elements back, we could theoretically release the lock without waiting for the reclaimed objects to finish being processed. Also validated that the `nomatch` handling is thread-safe - The cohort's `push_safe_obj` uses as CAS loop to safely add to the top of the list. Would multiple copies of an object be pushed into a cohort? No - An object is either in the retirement list (i.e. list) in the cohort, or it's been processed for reclamation. This guarantee already exists (the diff doesn't change that). This means the only way multiple copies of an object can be pushed back to the safe list is if we end up clearing the `tagged_` list within the domain - which is the synchronization / shared memory point. Since we do dequeue and enqueue of that list under a lock, an object should would never appear on that list. The only (shared object) change is around addition to the cohort's safe list, which is meant to be thread-safe. Reviewed By: yfeldblum Differential Revision: D51638674
|
This pull request was exported from Phabricator. Differential Revision: D51638674 |
instw
force-pushed
the
export-D51638674
branch
from
f80275e
to
c588122
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary:
PROBLEM
During reclamation of tagged objects, we obtain a lock within the hazard pointer domain's tagged list. This list supports always pushing objects, but only allows popping when there is a lock (for
tagged_).There is opportunity to improve the performance of reclamation, by keeping the
tagged_list locked for a smaller amount of time.SOLUTION
The list is locked to prevent multiple threads from reclaiming the same objects. During reclamation, we take all objects that are potentially cleaned up, and divide them into 2 parts: Those that must be reclaimed, and those that must not. The ones that are not are pushed back to the
tagged_list, and the list is unlocked. The objects to be reclaimed are freed - by pushing to the cohort.The locking of list is to guard against the
tagged_list itself, and hence when we push the not-to-be-reclaimed elements back, we could theoretically release the lock without waiting for the reclaimed objects to finish being processed.Also validated that the
nomatchhandling is thread-safe - The cohort'spush_safe_objuses as CAS loop to safely add to the top of the list.Differential Revision: D51638674