{"id":13632558,"url":"https://github.com/ibraheemdev/seize","last_synced_at":"2025-05-16T08:05:40.757Z","repository":{"id":36998432,"uuid":"451295668","full_name":"ibraheemdev/seize","owner":"ibraheemdev","description":"Fast, efficient, and robust memory reclamation for Rust.","archived":false,"fork":false,"pushed_at":"2025-02-18T21:41:04.000Z","size":302,"stargazers_count":413,"open_issues_count":4,"forks_count":15,"subscribers_count":7,"default_branch":"master","last_synced_at":"2025-05-15T09:55:10.537Z","etag":null,"topics":["concurrency","data-structures","garbage-collection","memory-management"],"latest_commit_sha":null,"homepage":"https://docs.rs/seize","language":"Rust","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/ibraheemdev.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null}},"created_at":"2022-01-24T02:52:36.000Z","updated_at":"2025-05-13T21:26:06.000Z","dependencies_parsed_at":"2023-09-24T17:57:13.680Z","dependency_job_id":"efead89a-25bb-4fd3-bede-df08cbf4617d","html_url":"https://github.com/ibraheemdev/seize","commit_stats":{"total_commits":124,"total_committers":3,"mean_commits":"41.333333333333336","dds":"0.024193548387096753","last_synced_commit":"a8e97dae081869e767dda86f86b0a824a0b543a6"},"previous_names":[],"tags_count":3,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ibraheemdev%2Fseize","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ibraheemdev%2Fseize/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ibraheemdev%2Fseize/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ibraheemdev%2Fseize/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/ibraheemdev","download_url":"https://codeload.github.com/ibraheemdev/seize/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":254493378,"owners_count":22080126,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["concurrency","data-structures","garbage-collection","memory-management"],"created_at":"2024-08-01T22:03:06.834Z","updated_at":"2025-05-16T08:05:35.749Z","avatar_url":"https://github.com/ibraheemdev.png","language":"Rust","funding_links":[],"categories":["Rust"],"sub_categories":[],"readme":"# `seize`\n\n[\u003cimg alt=\"crates.io\" src=\"https://img.shields.io/crates/v/seize?style=for-the-badge\" height=\"25\"\u003e](https://crates.io/crates/seize)\n[\u003cimg alt=\"github\" src=\"https://img.shields.io/badge/github-seize-blue?style=for-the-badge\" height=\"25\"\u003e](https://github.com/ibraheemdev/seize)\n[\u003cimg alt=\"docs.rs\" src=\"https://img.shields.io/docsrs/seize?style=for-the-badge\" height=\"25\"\u003e](https://docs.rs/seize)\n\nFast, efficient, and predictable memory reclamation for concurrent data\nstructures.\n\nRefer to the [quick-start guide] to get started.\n\n## Background\n\nConcurrent data structures are faced with the problem of deciding when it is\nsafe to free memory. Despite an object being logically removed, it may still be\naccessible by other threads that are holding references to it, and thus it is\nnot safe to free immediately. Over the years, many algorithms have been devised\nto solve this problem. However, most traditional memory reclamation schemes make\na tradeoff between performance and efficiency.\n\nFor example, [hazard pointers] track individual pointers, making them very\nmemory efficient but also relatively slow. On the other hand, [epoch based\nreclamation] is fast and lightweight, but lacks predictability, requiring\nperiodic checks to determine when it is safe to free memory. This can cause\nreclamation to trigger unpredictably, leading to poor latency distributions.\n\nAlternative epoch-based schemes forgo workload balancing, relying on the thread\nthat retires an object always being the one that frees it. While this can avoid\nsynchronization costs, it also leads to unbalanced reclamation in read-dominated\nworkloads; parallelism is reduced when only a fraction of threads are writing,\ndegrading memory efficiency as well as performance.\n\n## Implementation\n\n`seize` is based on the [hyaline reclamation scheme], which uses reference\ncounting to determine when it is safe to free memory. However, unlike\ntraditional reference counting schemes where every memory access requires\nmodifying shared memory, reference counters are only used for retired objects.\nWhen a batch of objects is retired, a reference counter is initialized and\npropagated to all active threads. Threads cooperate to decrement the reference\ncounter as they exit, eventually freeing the batch. Reclamation is naturally\nbalanced as the thread with the last reference to an object is the one that\nfrees it. This also removes the need to check whether other threads have made\nprogress, leading to predictable latency without sacrificing performance.\n\n`seize` provides performance competitive with that of epoch based schemes, while\nmemory efficiency is similar to that of hazard pointers. `seize` is compatible\nwith all modern hardware that supports single-word atomic operations such as FAA\nand CAS.\n\n[quick-start guide]: https://docs.rs/seize/latest/seize/guide/index.html\n[hazard pointers]:\n  https://www.cs.otago.ac.nz/cosc440/readings/hazard-pointers.pdf\n[hyaline reclamation scheme]: https://arxiv.org/pdf/1905.07903.pdf\n[epoch based reclamation]:\n  https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-579.pdf\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fibraheemdev%2Fseize","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fibraheemdev%2Fseize","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fibraheemdev%2Fseize/lists"}