docs: add source-linked adoption census (doc/adoption.md, v1.2.0) - #323
Conversation
Add doc/adoption.md, a versioned inventory of where libCacheSim is used, where every entry links to the primary source that supports it and states the class of evidence that source provides (vendored/forked, built on, used as-is, distributes, cites only). The first edition records: - research artifacts that vendor libCacheSim (GL-Cache FAST'23, S3-FIFO SOSP'23, SIEVE NSDI'24) and third-party work built on it (3L-Cache FAST'25, PolicySmith, Vulcan, DynamicAdaptiveClimb, SCION) - an independent cross-validation by the Caffeine maintainer (issue #18) - distribution channels (PyPI libcachesim, npm libcachesim-node, releases) with package state and download volume - ecosystem projects (CacheBench, cache_dataset) - repository signals, kept separate from sourced adoption - downstream SIEVE/S3-FIFO reimplementations, explicitly labelled as algorithm adoption rather than libCacheSim adoption - six candidates examined and rejected, with reasons, plus the known gaps of the method (no repo-wide code search, no citation-graph sweep, no DOI) Also documents how to reproduce the numbers, how to add an entry, and how to cite a specific edition by commit permalink. Linked from README.md and the doc/ index. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WCUG9YH1JDDnNwWwfg8hn4
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 8b5f956c1d
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| ``` | ||
| libCacheSim Adoption Census, version 1.0.0 (2026-08-13). | ||
| libCacheSim project documentation, doc/adoption.md. | ||
| https://github.com/1a1a11a/libCacheSim/blob/develop/doc/adoption.md |
There was a problem hiding this comment.
Pin the citation URL to this census commit
The recommended citation points to develop, even though the preceding text promises a commit-pinned permalink. Once this document is revised in place, that URL will resolve to the newest edition rather than v1.0.0, preventing readers from retrieving the exact cited census; use the immutable commit URL here and in the BibTeX entry.
Useful? React with 👍 / 👎.
| | Project | Class | Evidence | Source | | ||
| |---|---|---|---| | ||
| | **CacheBench** — benchmarking suite evaluating 18 eviction algorithms across thousands of traces, developed by Haocheng Xia (UIUC, visiting Harvard) under the UCSC OSPO Summer of Reproducibility | B | Report describes libCacheSim as a core component and the project as "a Python package that allows users to easily download traces and run simulation analyses using libCacheSim" | [UCSC OSPO report](https://ucsc-ospo.github.io/report/osre25/harvard/cachebench/2025-08-06-haochengxia/) | | ||
| | **cache_dataset** — open collection of production cache traces (Meta, Twitter, CloudPhysics, Microsoft, Wikimedia, Alibaba, Tencent) | B | "We provide both plain text format that is human readable and `oracleGeneral` format that is suitable for using with [libCacheSim] platform"; ships libCacheSim tutorials and notes it reads compressed traces directly | [cacheMon/cache_dataset](https://github.com/cacheMon/cache_dataset) | |
There was a problem hiding this comment.
Do not classify format compatibility as built-on adoption
Under this document's own definition, class B requires a work to be implemented on top of or extend libCacheSim, but the quoted evidence only says that this trace collection provides a format suitable for use with libCacheSim. Shipping compatible data or tutorials does not establish that cache_dataset itself is built on the library, so this row overstates the census unless a source showing actual implementation or execution is provided.
Useful? React with 👍 / 👎.
|
|
||
| | Version | Date | Change | | ||
| |---|---|---| | ||
| | 1.0.0 | 2026-08-13 | First edition. 8 adoption entries across research, distribution, and ecosystem; 6 candidates examined and rejected; repository signals and downstream algorithm adoption recorded separately. | |
There was a problem hiding this comment.
Correct the adoption-entry total
The census contains 14 rows assigned adoption classes A–D: nine research rows, three distribution rows, and two ecosystem rows. Recording only eight in the version changelog makes the historical summary inconsistent with the edition it describes and leaves future maintainers without a reliable baseline for tracking changes.
Useful? React with 👍 / 👎.
|
CI note: This branch changes three markdown files only (
Root cause. The macOS runner is now on Xcode 26.6, whose clang diagnoses Those lines were last touched in #252 (2025-07-09) and predate this branch. The Linux job is unaffected because GCC does not diagnose this. Suggested fix, for a separate PR. Making the conversion explicit silences it without changing behavior — // line 98
uint64_t sample_max = static_cast<uint64_t>(static_cast<double>(UINT64_MAX) * sample_rate);
// lines 215-216
sample_rate = min_value_map.get_max_value() * 1.0 / static_cast<double>(UINT64_MAX);I kept it out of this PR because a docs-only change should not carry an unrelated fix to the MRC profiler, and the fix wants its own review. Happy to open that PR if you want it. Generated by Claude Code |
There was a problem hiding this comment.
Pull request overview
Adds a new documentation artifact (doc/adoption.md) that inventories external adoption of libCacheSim with source links and evidence classes, and links it from the main README and the docs index.
Changes:
- Add
doc/adoption.md“Adoption Census” (versioned, source-linked inventory with reproduction notes). - Link the census from
README.mdanddoc/README.md.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| README.md | Adds a pointer to the new adoption census document. |
| doc/README.md | Adds the adoption census to the documentation index under a new “Project” section. |
| doc/adoption.md | Introduces the versioned adoption census with evidence classes, tables, and reproduction/citation guidance. |
Suppressed comments (1)
doc/adoption.md:242
- The BibTeX entry also uses the moving
developbranch URL even though the section recommends a commit-pinned permalink. Use the snapshot commit SHA in theurlfield to make the citation stable.
year = {2026},
month = aug,
url = {https://github.com/1a1a11a/libCacheSim/blob/develop/doc/adoption.md},
note = {Census date 2026-08-13; repository snapshot 7c169cf}
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
|
|
||
| | Version | Date | Change | | ||
| |---|---|---| | ||
| | 1.0.0 | 2026-08-13 | First edition. 8 adoption entries across research, distribution, and ecosystem; 6 candidates examined and rejected; repository signals and downstream algorithm adoption recorded separately. | |
| ``` | ||
| libCacheSim Adoption Census, version 1.0.0 (2026-08-13). | ||
| libCacheSim project documentation, doc/adoption.md. | ||
| https://github.com/1a1a11a/libCacheSim/blob/develop/doc/adoption.md | ||
| ``` |
Three corrections to doc/adoption.md, all raised in review: - Citation section contradicted itself: it instructed readers to cite a commit-pinned permalink and then supplied a mutable `develop` URL in both the plain citation and the BibTeX. A document cannot contain its own commit hash, so the section now explains how the citing reader resolves the pin (GitHub `y`, or git log on a clone), states the rule that an edition's permalink is the commit that bumped its version, and leaves `<commit>` as a fill-in. Also notes explicitly that 7c169cf in the header is the repository state described, not a permalink for this file — pinning to it would 404, since it predates the file. - Changelog undercounted the edition: it claimed 8 entries when the file carries 14 classed rows. Now broken down by section and by evidence class (4xA, 5xB, 3xC, 3xD over 14 rows), with the 8 third-party entries called out, so future editions have a real baseline. - cache_dataset was classed B (built on), which its own evidence does not support: publishing traces in a libCacheSim-readable format is not building on the library. Reclassified C (used as-is) on the strength of its three tutorial notebooks that run libCacheSim, with the format-compatibility distinction spelled out. Section 4 heading and its cross-reference updated to match. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WCUG9YH1JDDnNwWwfg8hn4
|
All three review points were valid and are fixed in f5cd355. 1. Citation pinned to a moving branch (@chatgpt-codex-connector, @copilot — both flagged it). The section told readers to cite a commit-pinned permalink and then handed them a 2. Entry count wrong. Confirmed by counting the classed rows: 14, not 8. The changelog now breaks it down by section (9 research / 3 distribution / 2 ecosystem), by evidence class (4×A, 5×B, 3×C, 3×D — 15 assignments over 14 rows, since the 3L-Cache row carries both A and B), and calls out that 8 of the 14 are third-party, which is the number I had conflated with the total. 3. In-page anchors and in-repo relative links were re-validated after the edits. Unchanged: Generated by Claude Code |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: f5cd355844
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| | Stars | 339 | | ||
| | Forks | 111 | | ||
| | Contributors (non-anonymous) | 36 | | ||
| | Open issues | 28 | |
There was a problem hiding this comment.
Separate pull requests from the open-issue count
When the repository has open pull requests, this value is not the number of open issues: the reproduction command on lines 199–200 reads GitHub's open_issues_count, which includes both issues and pull requests. This makes the census signal and future trend comparisons inaccurate; either label the row “Open issues and pull requests” or query the issues endpoint and exclude entries containing pull_request.
Useful? React with 👍 / 👎.
The "Open issues: 28" row took its value from the repository endpoint's open_issues_count, which GitHub defines as issues *plus* pull requests. The true split at census time is 21 open issues and 8 open pull requests (29 combined, one of which is this census's own PR). Reading that field as an issue count overstates the backlog and would corrupt trend comparisons between editions, so the row is now two rows with the pitfall stated inline. The reproduction snippet in section 9 drops open_issues_count and derives the split from /issues by filtering entries that carry a `pull_request` key, with a note about paginating past 100 open items so the count cannot truncate silently. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WCUG9YH1JDDnNwWwfg8hn4
|
Valid, and it was a wrong number rather than an imprecise label — fixed in 463d707.
The row is now two rows with the pitfall stated inline, since a future maintainer refreshing this section is exactly who would step on it again. The reproduction snippet in §9 drops Incidentally this PR demonstrated the bug while it was being reported: the field read 28 when the census was taken and 29 once #323 was opened, with no issue having been filed. Census version stays at 1.0.0 — the edition has not been published yet, so these are corrections to it rather than a new edition. Generated by Claude Code |
Summary
Testing
|
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 463d7075c8
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| 1,805 downloads over the 2026-02-12 → 2026-08-11 window available from the API, 258 of | ||
| them in the trailing 30 days. npm `libcachesim-node`: 173 downloads in the trailing | ||
| year ([npm downloads API](https://api.npmjs.org/downloads/point/last-year/libcachesim-node)). | ||
| Download counts include CI and mirror traffic and are a weak proxy for use; they are |
There was a problem hiding this comment.
State consistently whether mirror downloads are excluded
For the PyPI total, this caveat contradicts the heading on line 93 and the reproduction request's mirrors=false: readers are first told that mirrors were excluded, then that the reported download counts include mirror traffic. This affects how the 1,805-download baseline is interpreted in future trend comparisons; qualify the caveat by channel or state that the PyPI figure excludes the mirrors filtered by pypistats.
Useful? React with 👍 / 👎.
Self-audit of every quotation in the census against raw source text (raw.githubusercontent for READMEs, arXiv HTML full text for papers) rather than against rendered summaries. Two quotations did not survive: - DynamicAdaptiveClimb was quoted as "We use the libcachesim simulator for our experiments." That sentence does not occur anywhere in the paper. The paper says: "Simulator: We conduct all evaluations using libCacheSim [46], an open-source, high-performance, and extensible cache simulator widely adopted in recent caching research." Replaced. - SCION's artifact sentence was quoted as integrating "AdaptiveClimb/DynamicAdaptiveClimb"; the paper says "We integrate DynamicAdaptiveClimb into libCacheSim, build a trace-conversion and evaluation pipeline for HR-Cache". Replaced. Both originated as paraphrases from summarized fetches. Section 9 now states that quotations are matched against raw source text, records that this failure mode occurred, and gives the commands to re-check any row. Also from the audit: - 3L-Cache quote said "3L-Cache"; source reads "3L Cache". Corrected, and the fork sentence quoted in full. - Class E was defined and section 1 pointed at section 8 for E rows, but section 8 holds rejections and this edition has no E rows. Stated. - Section 3 now says outright that distribution channels are first-party reach, not third-party adoption, and the changelog counts them apart: 11 adoption entries (8 third-party) plus 3 channels = 14 sourced rows. - Download figures: the PyPI number excludes pypistats-recognized mirrors while npm applies no mirror filter, so the two are not comparable and neither excludes CI traffic. Previously the caveat contradicted the mirrors=false heading. - Gap 5 now records that DynamicAdaptiveClimb miscites the software to unrelated authors, concrete evidence for shipping a CITATION.cff. - ILRU recorded as an unverified lead rather than an entry, since the only support is another paper's related-work table. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WCUG9YH1JDDnNwWwfg8hn4
|
I re-audited the census against raw sources rather than waiting for review to find the rest. Pushed as daddf96. Two of my own quotations did not survive — the most serious defects in the document so far. Fabricated quotation (DynamicAdaptiveClimb). The row quoted "We use the libcachesim simulator for our experiments." That sentence does not appear anywhere in arXiv:2511.21235. The paper says:
Stronger evidence than what I had printed — but what I printed was not a quotation. Replaced. Paraphrase presented as quotation (SCION). I had the authors integrating "AdaptiveClimb/DynamicAdaptiveClimb" into libCacheSim; the paper says "We integrate DynamicAdaptiveClimb into libCacheSim, build a trace-conversion and evaluation pipeline for HR-Cache". Replaced. Both came from summarized fetches whose paraphrase I carried through as verbatim text. The other seven quotations verified exact against raw source, including the one this fixes them by: PolicySmith's "…a high-performance web cache simulator with an event-driven interface" is verbatim, ellipsis and all. §9 now states that quotations are matched against raw source text, records that this failure mode occurred in preparing this very edition, and gives the two commands to re-check any row — so the claim about provenance is now true, where before it was aspirational. Also fixed in the same pass:
On the follow-up PR proposing to hard-code the citation to Generated by Claude Code |
Summary
Testing
|
Removes "Known gaps and limitations", "Examined and not included", and "Reproducing this census" from the adoption census, renumbers the downstream-algorithm section from 7 to 6, and repairs everything that pointed into the removed text: the scope section's cross-reference, the class E note that pointed at the rejections table, the DynamicAdaptiveClimb row's link to the citation note, and the changelog's tally of rejected candidates. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WCUG9YH1JDDnNwWwfg8hn4
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: eac94d2728
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
|
||
| | Version | Date | Change | | ||
| |---|---|---| | ||
| | 1.0.0 | 2026-08-13 | First edition. **11 adoption entries** — 9 research (3 first-party artifacts, 5 third-party works, 1 independent cross-validation) and 2 ecosystem projects — of which **8 are third-party**. Plus 3 first-party distribution channels, which are reach rather than adoption, for **14 sourced rows** total. By evidence class: 4×A, 5×B, 3×C, 3×D (15 assignments over 14 rows — the 3L-Cache row carries both A and B). Repository signals and downstream algorithm adoption are recorded separately and excluded from every count above. | |
There was a problem hiding this comment.
Exclude cache_dataset from the third-party count
In the revised breakdown, the 8 third-party subtotal can only be reached by treating both ecosystem rows as third-party. However, cache_dataset is owned by the same cacheMon organization identified above as maintaining libCacheSim's first-party Python bindings, and this repository's README describes it as a dataset “we provide.” The third-party subtotal is therefore 7 (five §2.2 works, one independent cross-validation, and CacheBench), while the overall 11-adoption-entry and 14-sourced-row totals remain unchanged.
Useful? React with 👍 / 👎.
Ran a full-text and archive sweep beyond targeted search: OpenAlex fulltext.search (16 works), Software Heritage origin search, and the fork list. Every candidate was then checked against a primary source. New third-party entries: - Cache is King: Smart Page Eviction with eBPF (Zussman et al., Columbia and IBM Research). Class B: "We implement LHD using cachebpf, based on the implementation in libcachesim [69, 70, 72]." - MetaMuse: Algorithm Generation via Creative Ideation (Ma, Liang, Gao, Yan; Microsoft Research). Class C, used as trace generator: "For cache replacement, these n traces are generated by libCacheSim ... from different Zipfian distributions." - T3-LRU (Research Square preprint). Class A: evaluated in a libCacheSim fork archived on Zenodo as "rim99/libCacheSim: T3LRU Simulation". PolicySmith moved from arXiv preprint to its published venue, HotNets '25 (10.1145/3772356.3772413). Candidates checked and left out: CAPSULE, whose Zenodo record is retracted; ScaleOPT, which benchmarks against libCacheSim but whose text is paywalled and unverifiable here; CoNEXT'21 LHR and IEEE CLUSTER FIFO-MEP, same reason; and @realtmxi/libcachesim-node, which is prerelease staging of the in-tree binding rather than an independent republish. Ecosystem rows are now marked project-affiliated rather than third-party: cache_dataset sits in the cacheMon org and CacheBench was built by a project collaborator, so neither belongs in the third-party subtotal. Counts restated: 14 adoption entries (9 third-party), 3 distribution channels, 17 sourced rows, 5xA 6xB 4xC 3xD. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WCUG9YH1JDDnNwWwfg8hn4
|
Two updates in 6d3c5d6. Sections removed as requested. "Known gaps and limitations", "Examined and not included", and "Reproducing this census" are gone; the downstream-algorithm section renumbered 7 → 6, and every reference that pointed into the removed text was repaired. Wider sweep, four new verified entries. The earlier edition was built from targeted search, which is why it read as a lower bound. This pass added full-text and archive indexes: OpenAlex
Worth noting on the T3-LRU row: a third-party fork of this project now has a Zenodo DOI while upstream does not, so that fork is currently the more citable artifact. Checked and left out, since a lead is not evidence: CAPSULE (its Zenodo record is retracted — OpenAlex still indexes it); ScaleOPT (SIGMETRICS '25, benchmarks against libCacheSim as a baseline — credible, but ACM returns 403 here and neither the repo nor a preprint carries the sentence); CoNEXT '21 LHR and IEEE CLUSTER '25 FIFO-MEP (paywalled); and @chatgpt-codex-connector's point on the third-party subtotal was right, and applies one row further than reported: Counts restated: 14 adoption entries (9 third-party), 3 distribution channels, 17 sourced rows, 5×A / 6×B / 4×C / 3×D. Generated by Claude Code |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 6d3c5d6ac1
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| @@ -0,0 +1 @@ | |||
| <!DOCTYPE html><html lang="en-US"><head><title>Just a moment...</title><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><meta http-equiv="X-UA-Compatible" content="IE=Edge"><meta name="robots" content="noindex,nofollow"><meta name="viewport" content="width=device-width,initial-scale=1"><meta http-equiv="content-security-policy" content="default-src 'none'; script-src 'nonce-B8w5t2wQCCaL7XTMpdWtre' 'unsafe-eval' https://challenges.cloudflare.com; script-src-attr 'none'; style-src 'unsafe-inline'; img-src 'self' https://challenges.cloudflare.com; connect-src 'self' https://challenges.cloudflare.com; frame-src 'self' https://challenges.cloudflare.com blob:; child-src 'self' https://challenges.cloudflare.com blob:; worker-src blob:; form-action http: https:; base-uri 'self'"><style>*{box-sizing:border-box;margin:0;padding:0}html{line-height:1.15;-webkit-text-size-adjust:100%;color:#313131;font-family:system-ui,-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,"Helvetica Neue",Arial,"Noto Sans",sans-serif,"Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol","Noto Color Emoji"}body{display:flex;flex-direction:column;height:100vh;min-height:100vh}.main-content{margin:8rem auto;padding-left:1.5rem;max-width:60rem}@media (width <= 720px){.main-content{margin-top:4rem}}#challenge-error-text{background-image:url("data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSIzMiIgaGVpZ2h0PSIzMiIgZmlsbD0ibm9uZSI+PHBhdGggZmlsbD0iI0IyMEYwMyIgZD0iTTE2IDNhMTMgMTMgMCAxIDAgMTMgMTNBMTMuMDE1IDEzLjAxNSAwIDAgMCAxNiAzbTAgMjRhMTEgMTEgMCAxIDEgMTEtMTEgMTEuMDEgMTEuMDEgMCAwIDEtMTEgMTEiLz48cGF0aCBmaWxsPSIjQjIwRjAzIiBkPSJNMTcuMDM4IDE4LjYxNUgxNC44N0wxNC41NjMgOS41aDIuNzgzem0tMS4wODQgMS40MjdxLjY2IDAgMS4wNTcuMzg4LjQwNy4zODkuNDA3Ljk5NCAwIC41OTYtLjQwNy45ODQtLjM5Ny4zOS0xLjA1Ny4zODktLjY1IDAtMS4wNTYtLjM4OS0uMzk4LS4zODktLjM5OC0uOTg0IDAtLjU5Ny4zOTgtLjk4NS40MDYtLjM5NyAxLjA1Ni0uMzk3Ii8+PC9zdmc+");background-repeat:no-repeat;background-size:contain;padding-left:34px}</style><meta http-equiv="refresh" content="360"></head><body><div class="main-wrapper" role="main"><div class="main-content"><noscript><div class="h2"><span id="challenge-error-text">Enable JavaScript and cookies to continue</span></div></noscript></div></div><script nonce="B8w5t2wQCCaL7XTMpdWtre">(function(){window._cf_chl_opt = {cFPWv: 'g',cH: 'a.Hr72g.6z8AsQw0tQK_db5NBQDxmMWAGH0OpVr7sQI-1786581293-1.2.1.1-LHtp3XPCWmEGEhlVJTBZwnPIWg6kHTxmmhOhzzfyGeFYChQBTGZzaFT_M2UkwmME',cITimeS: '1786581293',cN: 'B8w5t2wQCCaL7XTMpdWtre',cRay: 'a2a3a2ff788df45a',cTplB: '0',cTplC:0,cTplO:0,cTplV:5,cType: 'managed',cUPMDTk:"/doi/10.1145/3700426?__cf_chl_tk=9Ing9mpHMFU9Y6e8jBaGvUgziszo2nZSa4FZfgKqtqQ-1786581293-1.0.1.1-et9Xnh01BWk9x_f5bZqmsVQhnk4.5WZq5XukUqm9r7U",cvId: '3',cZone: 'dl.acm.org',fa:"/doi/10.1145/3700426?__cf_chl_f_tk=9Ing9mpHMFU9Y6e8jBaGvUgziszo2nZSa4FZfgKqtqQ-1786581293-1.0.1.1-et9Xnh01BWk9x_f5bZqmsVQhnk4.5WZq5XukUqm9r7U",md: 'oMKb6.8tJ8HeGnKWYX4biJPyPLzSaIiZwIgN8XzxATk-1786581293-1.2.1.1-LJ04MmJtBG6TQlWqtmaddnFIXbiEN5riyH.2W5s02Yr.CegSPUyU3QpWIWD25K5yvku1lyzb56MfSK522C.AWbCdLQE2rTUN1HRin_vF5M9bFMSDHjI.UFuQAhc4un39AJguUolA.KbggCxdLgef2WZ5rH7.NXYU5U8t6915F3YfOznwJIXnlywX3oEHqfP2Fb_S8Caftu4yrFUsXeE8JQnZhf8k9nGhSvblm72DhDCPUVQKi6KCMwXhjBntCuyPlCZhODm.2sK25lvgiUoh0413ctgFGnkQcq25aVjIu9zy7HyjQBBcSu7LI9tLP1Z0EhCJ5iKblM0D9F7zfTbJIeHn5LdhFg07zLnGpTA1T55Om9nEJLkhaYRvmhbHgRpR8LBLq8o_hOxR2t2l9knX04VfPgzme6hHk6NV7xMWKmyQV9d8U09tbEOZVvREiWwmsgLezW3vz7tLTmJdCeA8SEr8HCL3vFWroUrnNubZlAZl3yaXxucbKt5qHa9Dd4.vGsnLin96G70PS2TCtMNiIGxqzR1Zq2Iq1zBOwrHRhIZEQozqg4DL66WO9Z_HH8DK52kQP7KyZk9R8V6YBTa8yeZSZTYzHN0UOiAF4nc9wh2oxRVJP33aV4DuEmLjppEBpTotzNFJYv0yDM8exdyxXcOHKNZpvIRZ98922S6kNXSZEg52e9EII.WmpE3Kaoga_Vorz0BBM89U1YGfWQokqvXuIBBfugwbcy1592nDXuKPOibaf9wLrCIa36Sr0MJc8iIwLq4c3wcpHQl9Bekv4lCXNIHWuvtL6.KL7XTAw6Qlay6cUJZpuUCiKnpKhYrVE.fiubv7_NSgLhSkJXpCoAynEJMy8kP5d1IfZcYatbu_dS44iPN1Dwj0yQ81s4SeUfZ2SMWiVEcGLyseGS3OhX5luZseDGvNlm0ZTn9ahQyQYvzjbGfQo7G9s6sWrN77wQiS.eyPYBjTyizoFpRIwuJOTf2oQdBntww128qtxivqIR4YWtzVvkgF0498owwF6vpR_uo.AipoGqvQXtquA8Dcu3m_EPR4ZQ_YJA5dvne_b8CR_V0voGlpoHqSHidFw32yWkwuc4Blv2P1SUbtUw',mdrd: '14Vb4kuzvfUgFxxgT8_yCHZIPD.poB2AIJ6gNDDERTk-1786581293-1.2.1.1-uTGKF52NKVv_AuE9vTd2IDZXce4mj4P0j4CGeCUXvZIOymkSMi5bAgMWJe2_uhOU.mBd3V4BvgS.zwMkV7iU4NUDvBGGnITdd_X8VObpZQ.nyUfCleIJpLoLvtqe3FQQowM4CYeNSF7kIK4zrxONzzMb5umWk.zSvl6.Rn24tR5TuuM0dVm_DDphYKDZlsq5hmfuhxLnRonPWn3B60hXyg',};var a = document.createElement('script');a.nonce = 'B8w5t2wQCCaL7XTMpdWtre';a.src = '/cdn-cgi/challenge-platform/h/g/orchestrate/chl_page/v1?ray=a2a3a2ff788df45a';window._cf_chl_opt.cOgUHash = location.hash === '' && location.href.indexOf('#') !== -1 ? '#' : location.hash;window._cf_chl_opt.cOgUQuery = location.search === '' && location.href.slice(0, location.href.length - window._cf_chl_opt.cOgUHash.length).indexOf('?') !== -1 ? '?' : location.search;if (window.history && window.history.replaceState) {var ogU = location.pathname + window._cf_chl_opt.cOgUQuery + window._cf_chl_opt.cOgUHash;history.replaceState(null, null,"/doi/10.1145/3700426?__cf_chl_rt_tk=9Ing9mpHMFU9Y6e8jBaGvUgziszo2nZSa4FZfgKqtqQ-1786581293-1.0.1.1-et9Xnh01BWk9x_f5bZqmsVQhnk4.5WZq5XukUqm9r7U"+ window._cf_chl_opt.cOgUHash);a.onload = function() {history.replaceState(null, null, ogU);}}document.getElementsByTagName('head')[0].appendChild(a);}());</script></body></html> No newline at end of file | |||
There was a problem hiding this comment.
Remove the captured Cloudflare challenge page
This file is a failed ACM fetch rather than project documentation: it contains a transient Cloudflare challenge token and loads executable challenge code from challenges.cloudflare.com. A repo-wide search at this commit finds no reference to acm_scaleopt.html, so source archives now unnecessarily ship an unusable and potentially confusing third-party interstitial; remove the captured response instead of committing it.
Useful? React with 👍 / 👎.
acm_scaleopt.html was a failed dl.acm.org fetch (a Cloudflare challenge page) written into the repository root while verifying the ScaleOPT candidate, then swept in by `git add -A`. It is not project documentation, nothing references it, and it embeds a transient challenge token and a script tag pointing at challenges.cloudflare.com. Removed; the branch now touches only README.md, doc/README.md, and doc/adoption.md. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WCUG9YH1JDDnNwWwfg8hn4
Summary
Testing
|
Adds a section 2.4 for use outside the publication record, plus a trace-format interoperability subsection, from a parallel search sweep. Every quotation below was re-verified against raw source text. Section 2.4: - Marc Brooker (engineer at AWS): "Using the excellent open source libCacheSim I tried SIEVE-2 against SIEVE on a range of real-world traces", and "I've implemented SIEVE-k in a fork of libCacheSim". The fork carries Sieve_k.c in the eviction directory. - Three Chameleon Cloud reproducibility artifacts implementing CLOCK-Pro and CAR on libCacheSim and demonstrating AdaptSize, found by scanning all 460 public Trovi artifacts. - gws8820/2-Level-libCacheSim, a fork extending the simulator to two cache levels. Trace-format interoperability: Pelikan's Rust cachesim, Otter, and Caffeine each implement readers for libCacheSim's trace formats. By the same rule that keeps cache_dataset out of class B, reimplementing a format is not adoption, so these count toward no total; they are recorded because oracleGeneral is functioning as a de-facto interchange format. PolicySmith moves from class B to A + B: its artifact vendors libCacheSim as a git submodule pointing at ldos-project/libcachesim, verified from the repository's .gitmodules. Counts restated: 19 adoption entries (14 third-party), 3 distribution channels, 22 sourced rows, 8xA 8xB 6xC 3xD. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WCUG9YH1JDDnNwWwfg8hn4
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: cbe4088ffb
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| |---|---|---|---|---| | ||
| | 3L-Cache: Low Overhead and Precise Learning-based Eviction Policy for Caches — Wenbin Zhou, Zhixiong Niu, Yongqiang Xiong, Juan Fang, Qian Wang (Beijing Univ. of Technology; Microsoft Research) | FAST '25 | A + B | Artifact README: "3L Cache is implemented in the [libCacheSim] library, and its experimental environment configuration is consistent with libCacheSim"; repository layout notes "Forked from LibCacheSim, which is a platform for cache evaluation". The algorithm was subsequently upstreamed into this repository. | [optiq-lab/3L-Cache](https://github.com/optiq-lab/3L-Cache), [USENIX](https://www.usenix.org/conference/fast25/presentation/zhou-wenbin), [issue #119](https://github.com/1a1a11a/libCacheSim/issues/119), [`3LCache/`](/libCacheSim/cache/eviction/3LCache/) | | ||
| | Man-Made Heuristics Are Dead. Long Live Code Generators! (PolicySmith) — Dwivedula, Saxena, Akella, Chaudhuri, Kim (UT Austin) | HotNets '25 | A + B | "Our prototype is built on libCacheSim, a high-performance web cache simulator with an event-driven interface." The artifact — "All code used for these case studies is available at https://github.com/ldos-project/policysmith" — vendors libCacheSim as a submodule: `[submodule "webcache/libCacheSim"] … url = git@github.com:ldos-project/libcachesim.git`. | [ACM DL](https://doi.org/10.1145/3772356.3772413), [arXiv:2510.08803](https://arxiv.org/abs/2510.08803), [ldos-project/policysmith](https://github.com/ldos-project/policysmith) | | ||
| | Cache is King: Smart Page Eviction with eBPF — Zussman, Zarkadas, Carin, Cheng, Franke, Pfefferle, Cidon (Columbia; IBM Research) | arXiv, Feb 2025 | B | "We implement LHD using cachebpf, based on the implementation in libcachesim [69, 70, 72]." The eBPF page-cache port is derived from libCacheSim's LHD implementation. | [arXiv:2502.02750](https://arxiv.org/abs/2502.02750) | |
There was a problem hiding this comment.
Treat the LHD port as downstream implementation adoption
Under the census's declared criteria, this evidence does not establish class B adoption: the quoted sentence says the authors implemented LHD in cachebpf based on libCacheSim's implementation, not that their work runs, bundles, or is implemented on top of libCacheSim. This is the same kind of downstream reimplementation that §6 explicitly excludes, so counting it inflates the research, third-party, and class-B totals unless a source demonstrating actual libCacheSim use is added.
Useful? React with 👍 / 👎.
Second search sweep, every quotation verified against raw source text. First-party artifacts previously missing (section 2.1): - HotOS'23 QD-LP: "The repo is a snapshot of libCacheSim, which contains the implementation of the algorithms compared in the paper." - S4-FIFO (OSDI'26) and Demystifying and Improving Lazy Promotion in Cache Eviction (VLDB'26), both cacheMon artifacts built on it. Two existing rows gain artifacts and a class: - DynamicAdaptiveClimb -> C + A. Dhruv27Mishra/Adaptive-Climb vendors the simulator and adds AdaptiveClimb.c and DynamicAdaptiveClimb.c. - SCION -> B + A. Icemap/SCION pins cacheMon/libCacheSim at f7c85f8 and applies its own patch. New third-party ecosystem row: sys-intelligence/system-intelligence-benchmark invokes the built cachesim binary to score LLM-designed eviction policies. Cache is King moves out of the third-party table into a new "Derived implementations and trace-format interoperability" section, counted nowhere. Its evidence is that the authors ported libCacheSim's LHD implementation into eBPF, which under this document's own class definitions is neither building on nor running the software - the same distinction that keeps format compatibility out of class B. Raised in review; the classification was wrong as it stood. Also records a negative result that took a full sweep to establish: no third-party redistribution of libCacheSim exists anywhere (AUR, conda-forge, vcpkg, conan, Debian, Homebrew, Nix, crates.io, Docker Hub), and deps.dev reports zero reverse dependencies for the PyPI package. Counts restated: 22 adoption entries (14 third-party), 3 distribution channels, 25 sourced rows, 12xA 8xB 7xC 3xD. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WCUG9YH1JDDnNwWwfg8hn4
Google Scholar is reachable from this environment, and a full-text sweep of USENIX proceedings (FAST/ATC/OSDI/NSDI '23-'26), all HotNets '23-'25, and all PVLDB vol. 16-19 turned up work the earlier passes missed. Every quotation verified against raw source text. New third-party entries: - FLOWS (EuroSys '24, HUST / UT Arlington / Tencent): "we employ libCachesim [3] ... We have extended libCachesim to incorporate additional features such as cache size adjustment, MRC generation, and cache instance balancing." - ScaleOPT (POMACS / SIGMETRICS '25), previously left out as unverifiable, now sourced to the publisher-deposited abstract, which benchmarks against libCacheSim as one of "two widely-used cache simulators". - Intent-Driven Storage Systems: "We then evaluated all the traces for all policies using libcachesim ... at 0.1% of the working set." - L. Stampf's BSc thesis (VU Amsterdam), which used the simulator and produced upstream macOS build fixes: PRs #179 and #181 merged, #183 not. First-party rows filled in from the papers themselves: the S4-FIFO row is now the OSDI '26 paper it belongs to (Learning-Augmented Heuristics), the Lazy Promotion row carries its PVLDB citation and quote, and Clock2Q+ (VMware vSAN) and the author's CMU dissertation are added. The OSDI '20 paper is recorded as the origin of the simulator - "We built an open-source simulator called libCacheSim [71]" - and deliberately counted as neither first-party adoption nor third-party. MetaMuse moves from preprint to its published venue, ICLR '26. Correction: the three Chameleon Cloud artifacts were counted as third-party. Two of their authors turn out to be co-authors on libCacheSim-team papers (OSDI '26 and PVLDB '26), so the cohort is a course or mentorship programme around the project. They are now marked project-affiliated and excluded from the third-party subtotal. Counts restated: 28 adoption entries (15 third-party), 3 distribution channels, 31 classed rows, 12xA 9xB 13xC 3xD. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WCUG9YH1JDDnNwWwfg8hn4
Two review points, both correct. SCION was class B + A. Class A means the source tree contains a copy or fork of libCacheSim, but SCION's artifact carries only fetch-and-patch machinery: it clones upstream at a pinned commit and applies its own patch file. That is building on the software, not vendoring it, so the A is dropped and the row explains why. The neighbouring PolicySmith row keeps its A, and now says why the cases differ - its submodule points at a fork the same organisation maintains rather than at upstream. The npm download figure cited the rolling `last-year` endpoint, which returns a different interval to anyone opening it later and so cannot support the recorded value of 173. Replaced with the fixed-range query for 2025-08-10 to 2026-08-09, verified to return exactly 173. pypistats has no fixed-range equivalent, so the PyPI row states its window dates and says plainly that reproducing the figure means summing those dates out of a rolling response. Class tally restated: 11xA, 9xB, 13xC, 3xD over 31 rows. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WCUG9YH1JDDnNwWwfg8hn4
|
Both correct, fixed in f03acf7. SCION loses its class A. Class A means the source tree contains a copy or fork; SCION's artifact carries only fetch-and-patch machinery — it clones upstream at a pinned commit and applies its own patch file. That is building on the software, not vendoring it. Row is now B, with the reasoning stated inline. The comparison this forces is worth spelling out, so I did it in the document: the neighbouring PolicySmith row keeps its A because its submodule points at npm download figure re-pinned. It cited the rolling One correction to the fix, in the interest of not overstating it: pypistats has no fixed-range equivalent — it only serves a rolling window. So rather than claim both figures are now pinned, the PyPI row states its window dates and says plainly that reproducing that number means summing those dates out of a rolling response. Only the npm link is truly reproducible by clicking it. Generated by Claude Code |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: f03acf776b
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| a course or mentorship programme around the project. They are excluded from the | ||
| third-party subtotal for that reason. Marc Brooker, `gws8820`, and the VU Amsterdam |
There was a problem hiding this comment.
Do not infer affiliation for the entire Trovi cohort
The only affiliation evidence given is that two of the three artifact authors later co-authored papers with libCacheSim contributors; that does not establish that Raden Rafly Hanggaraksa Budiarto—or the cohort collectively—participated in a project course or mentorship program. Excluding all three from the third-party subtotal therefore makes the reported total of 15 unverifiable; either cite a source connecting the third artifact to the project or leave it in the third-party/unknown count.
Useful? React with 👍 / 👎.
The census excluded all three Chameleon Cloud artifacts from the third-party subtotal on the grounds that the cohort was a course or mentorship programme around the project. The evidence supported that for two authors only: Bintang Dwi Marthen co-authors the OSDI '26 paper and Muhammad Haekal Muhyidin Al-Araby the PVLDB '26 one. Raden Rafly Hanggaraksa Budiarto has no established link - he shares an institution with Marthen and published within ten days, which is suggestive but is not a source. Affiliation is now stated per author, with institutions taken from the Trovi artifact metadata, and the unlinked author is counted as third-party, the default when no affiliation can be shown. Third-party subtotal corrected from 15 to 16. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WCUG9YH1JDDnNwWwfg8hn4
|
Correct — I generalised from two authors to three, which is exactly the inference this document is supposed to refuse. Fixed in f5fd548. Affiliation is now stated per author, with institutions taken from the Trovi artifact metadata rather than inferred:
Budiarto's row is counted as third-party, the default when no affiliation can be shown, and the "suggestive but unproven" reasoning is written into the document rather than silently resolved. Third-party subtotal corrected 15 → 16. Worth noting the direction of this one: my error made the census understate third-party adoption, where the earlier errors overstated it. The fix moves a row back into the third-party count. Generated by Claude Code |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: f5fd548b02
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| that moves with the reader. pypistats offers no equivalent fixed-range endpoint — it | ||
| serves a rolling window — so the PyPI figure states its start and end dates above, and | ||
| reproducing it means summing those same dates out of the response. |
There was a problem hiding this comment.
Archive the rolling PyPI response
Because the pypistats response exposes a rolling window, once the window advances it drops the earliest dates and readers can no longer sum the stated 2026-02-12–2026-08-11 interval to reproduce the 1,805-download baseline. Stating the dates therefore does not make this edition reproducible; archive or commit the exact mirrors=false response used for the census.
Useful? React with 👍 / 👎.
Stating the window dates does not make the PyPI number checkable: the pypistats endpoint serves a rolling ~180-day window that drops its earliest days as it advances, so summing 2026-02-12 to 2026-08-11 will not return 1,805 once the window has moved. The document now says so outright and labels the figure a point-in-time observation recorded on the census date rather than a verifiable claim, alongside the npm figure which is genuinely reproducible from its fixed-range query. Not doing what the review suggested, and saying why: committing the raw response would record provenance but would not make the number independently checkable, since a reader would then be trusting this project's own copy of it. The honest fix is the caveat, not an archive. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WCUG9YH1JDDnNwWwfg8hn4
|
The diagnosis is right, and my previous fix was insufficient — stating the dates does not make the number checkable, because the rolling window drops its earliest days as it advances. Fixed in 452f150, though not by the suggested route. The document now says outright that the PyPI figure is not reproducible and cannot be made so: summing 2026-02-12 → 2026-08-11 will not return 1,805 once the window has moved, so it is labelled a point-in-time observation recorded on the census date rather than a verifiable claim. The npm figure sits next to it as the contrast — genuinely reproducible from its fixed-range query. I did not commit the raw response, and the document says why. Archiving this project's own copy of the response would record provenance but would not make the number independently checkable — a reader would be trusting our copy of it rather than the source. That is a weaker property than the census's other rows have, where anyone can open a pinned commit and read the quoted sentence for themselves. Given the choice between a caveat that is honest about the limit and an artifact that looks like verification without being it, the caveat is the better fix. Happy to add the archive anyway if you'd prefer the provenance trail on the record — it is about 10 KB of JSON — but it would want to be labelled as provenance, not as evidence. Generated by Claude Code |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 452f150bfc
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| **No third-party redistribution exists.** Every package of libCacheSim is published by | ||
| the project itself. Checked and found nothing: AUR, conda-forge/anaconda.org, vcpkg, | ||
| conan-center-index, Debian, Homebrew, Nix, and crates.io carry no libCacheSim port, and | ||
| Docker Hub returns one image, the project's own. deps.dev and GitHub's dependency graph |
There was a problem hiding this comment.
Include the Docker image in distribution totals
This sentence establishes that the project publishes a first-party Docker Hub image, which satisfies class D just like the other packaged distribution channels and is explicitly usable via the repository's dockerfile. Omitting it from the table makes the changelog's distribution totals inconsistent: there should be 4 distribution channels, 32 classed rows, 4×D, and 37 assignments unless the image is intentionally excluded with a stated reason.
Useful? React with 👍 / 👎.
Two parallel sweeps - a Google Scholar pass and an OpenAlex/Semantic Scholar citation-graph pass over ~690 conference PDFs - independently converged on the same set of works. Quotations re-extracted here with pypdf from the publisher PDFs. - Merlin (OSDI '26, Peking University, Michigan Tech, UCLA): "We implemented Merlin in both CacheLib [11] ... and libCacheSim [2]", with hit rates evaluated in libCacheSim and flash-friendliness on an extension of it. The authors state they contributed a CAR implementation upstream; that is recorded as their claim, since this repository's history does not attribute CAR.c to them. - Linear Elastic Caching via Ski Rental (CIDR '25, Google): "We implemented our ski rental based algorithms in libCacheSim [1]." The paper reports the resulting policy deployed in Spanner; the row says so without implying libCacheSim itself runs in production. - Writeback Modeling (MEMSYS '21, Rochester and Michigan Tech): "The simulator is based on libCacheSim [36]". At 2021 this is the earliest third-party use in the census. Adds the Docker Hub image as a fourth distribution channel, raised in review: the negative-result paragraph already established that the project publishes one, which makes it class D like the other channels. 1,014 pulls as of the census date. Not added, and worth recording why: the CoNEXT '21 and ATC '22 papers by Yan et al. are now readable via NSF PAR, but both say only that their implementation "benefits from existing caching simulators such as libCacheSim". That is a derivation gesture, not a statement of use, and does not clear the bar. Counts restated: 31 adoption entries (19 third-party), 4 distribution channels, 35 classed rows, 11xA 12xB 14xC 4xD. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WCUG9YH1JDDnNwWwfg8hn4
|
Docker point taken — added in fd8627a, along with three new papers from the final two search sweeps. Docker Hub is now a fourth distribution channel. You were right that the negative-result paragraph already established the project publishes one, which makes it class D exactly like PyPI and npm. Three new third-party works, found by a Google Scholar pass and an OpenAlex/Semantic Scholar citation-graph pass that independently converged on the same set — quotations re-extracted here with
Two care points on those rows. Merlin's authors state they "contributed … an implementation of CAR to libCacheSim"; Not added, and the reasoning is recorded: the CoNEXT '21 and ATC '22 papers by Yan et al. became readable via NSF PAR, but both say only that their implementation "benefits from existing caching simulators such as libCacheSim". That is a derivation gesture, not a statement of use, so it does not clear the bar — the same call already applied to Cache is King. Counts: 31 adoption entries, 19 third-party, 35 classed rows, 11×A 12×B 14×C 4×D. Generated by Claude Code |
Drops the A-E evidence classes and everything that existed to serve them: the class definitions table, the Class column in every table, the class tallies in the changelog, and the rationale paragraphs arguing why individual rows sat in one class rather than another. What the classes were carrying is now carried by the quotation itself - each row's evidence sentence already says whether the work forked, extended, ran, or shipped libCacheSim, so the letter was a second encoding of information the reader could see directly. Also flattened the structure: nine numbered sections and subsections become seven, the cross-validation subsection folds into practitioner use, and the borrowed-implementation, trace-format, and downstream algorithm tables merge into a single "Related but not adoption" section. Trimmed the distribution and citation prose to the facts. No entry, quotation, or source link was removed - all 31 adoption entries, 4 distribution channels, and the pinned commit URLs are intact. The file is 206 lines, down from 338. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WCUG9YH1JDDnNwWwfg8hn4
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 1756c213ae
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| |---|---|---| | ||
| | **CacheBench** — benchmarking suite evaluating 18 eviction algorithms across thousands of traces, built by Haocheng Xia under the UCSC OSPO Summer of Reproducibility | Describes libCacheSim as a core component, and the project as "a Python package that allows users to easily download traces and run simulation analyses using libCacheSim" | [UCSC OSPO report](https://ucsc-ospo.github.io/report/osre25/harvard/cachebench/2025-08-06-haochengxia/) | | ||
| | **system-intelligence-benchmark** — suite scoring LLM-designed systems heuristics; its `cache_algo_bench` task scores candidate eviction policies | Shells out to the built binary: `{LIBCACHSIM_PATH}/_build/bin/cachesim {cache_trace} oracleGeneral {cache_alg} {cache_cap} …` | [sys-intelligence/system-intelligence-benchmark](https://github.com/sys-intelligence/system-intelligence-benchmark/tree/46596edd8113a3eaf5646e49a42cc2a9fae3de4d) | | ||
| | **cache_dataset** — production cache traces (Meta, Twitter, CloudPhysics, Microsoft, Wikimedia, Alibaba, Tencent) | Ships tutorial notebooks that run libCacheSim, and publishes traces in its `oracleGeneral` format | [cacheMon/cache_dataset](https://github.com/cacheMon/cache_dataset/tree/a005343f26f47110de5c8d78d645ee89bee1e7ed) | |
There was a problem hiding this comment.
Provide direct evidence for the cache_dataset row
This row contains only a paraphrase and links to the repository root, so readers cannot directly verify which notebooks execute libCacheSim or what text supports the claim. That violates the census's stated guarantee that every entry includes a verbatim sentence from a checkable primary source; restore the notebook quotations and link to their exact pinned paths.
Useful? React with 👍 / 👎.
| **No third-party redistribution exists.** AUR, conda-forge, vcpkg, conan-center-index, | ||
| Debian, Homebrew, Nix, and crates.io carry no libCacheSim port; the single Docker Hub | ||
| image is the project's own; deps.dev and GitHub's dependency graph report zero reverse | ||
| dependencies for the PyPI package. |
There was a problem hiding this comment.
Qualify the no-redistribution claim
The absolute claim that no third-party redistribution exists conflicts with the T3-LRU entry above, which explicitly identifies a third-party libCacheSim fork archived and distributed as software through Zenodo. If this sweep is intended to cover only package registries and container images, say so; otherwise the Zenodo distribution needs to be included in the result.
Useful? React with 👍 / 👎.
…g claim Simplifying the census dropped the quotations from four rows, breaking the guarantee stated in its own opening line that every entry quotes a primary source. Raised in review for cache_dataset; a sweep of every evidence cell found three more with the same defect. - cache_dataset: restored the three notebook titles and the format sentence, and the source now links the README at a pinned commit rather than the repository root. - system-intelligence-benchmark: the invocation is quoted in full and attributed to the file it comes from. - Caffeine: quotes the reader import from TraceFormat.java instead of naming the enum constants alone. - TiDB: replaced "implements a SIEVE cache" with the file name plus the algorithm's reference bit, "visited bool". Also qualifies the redistribution claim, which as written contradicted an entry two sections above it. The sweep covered package registries and container images, so it now says no third-party *packaging* exists and names the one third-party redistribution found anywhere: the T3-LRU fork archived with a DOI on Zenodo. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WCUG9YH1JDDnNwWwfg8hn4
|
Both are regressions from the simplification pass, fixed in 06d2d55. Missing evidence — and it was worse than reported. You flagged
A document whose first line promises a quotation per entry should be checkable against that promise mechanically, so that scan is worth re-running on any future edit. Packaging claim qualified. You're right that "no third-party redistribution exists" contradicted the T3-LRU row two sections above, which is precisely a third party redistributing a modified copy — archived with a DOI on Zenodo. The sweep covered package registries and container images, so the claim now says no third-party packaging exists and names the Zenodo-archived fork as the one redistribution found anywhere. That is the second time the Zenodo fork has proved the more interesting artifact: it also has a DOI while upstream does not. Generated by Claude Code |
…nsus-versioned-repo-hwhp9m
|
CI is fully green and this is now mergeable. Correcting the record, since several comments above say The pre-existing The merge brought in only the two The PR description has been updated so it no longer tells reviewers to expect a red check. Awaiting review from @haochengxia — no human comments yet. Everything raised so far has come from the automated reviewers, and all of it has been addressed; the running summary is in the comments above. Generated by Claude Code |
Removes every first-party entry, so the census measures reach rather than the project citing itself: - drops the "First-party papers and artifacts" section (9 rows: the OSDI '20 origin paper, GL-Cache, S3-FIFO, SIEVE, QD-LP, S4-FIFO, Lazy Promotion, Clock2Q+, and the CMU dissertation), replaced by one sentence in Scope stating the exclusion so a reader cannot mistake it for an oversight - drops the two Chameleon Trovi artifacts whose authors co-write with the project, keeping Budiarto's, which has no established link - drops CacheBench and cache_dataset, both project-affiliated, and folds the one remaining ecosystem row into practitioner and community use - renumbers the sections and repoints every internal anchor The 19 entries that remain are exactly the 19 the previous edition counted as third-party, so the totals are unchanged in substance. Repository signals refreshed against the API: 340 stars, 9 open PRs, open_issues_count 30. Snapshot moved to develop @ dc80ebf. All 32 quoted spans are byte-identical to the previously verified edition; in-page anchors, repo-relative links, and commit pinning re-checked. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WCUG9YH1JDDnNwWwfg8hn4
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 638755ad9b
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| | Version | Date | Change | | ||
| |---|---|---| | ||
| | 1.1.0 | 2026-08-13 | Removed first-party entries: the section of the project's own papers and artifacts, two Chameleon artifacts by project co-authors, and the CacheBench and cache_dataset ecosystem rows. Every remaining entry is third-party. 19 entries — 13 third-party research, 6 practitioner, community, and ecosystem — plus 4 distribution channels. Repository signals refreshed. | | ||
| | 1.0.0 | 2026-08-13 | First edition. 31 entries — 8 first-party papers and artifacts, 13 third-party works, 7 practitioner and community entries, 3 ecosystem projects — of which 19 are third-party, plus 4 distribution channels. Separately recorded and not counted: the OSDI '20 paper that introduced the simulator, 4 borrowed-implementation and trace-format rows, 2 downstream algorithm adopters, and repository signals. | |
There was a problem hiding this comment.
Record all nine first-party rows in v1.0.0
The newly added v1.1 exclusion paragraph provides fresh evidence that the historical total is still off: it enumerates the OSDI '20 origin plus eight other first-party works, so v1.0.0 had 9 first-party rows and 32 entries overall (9 + 13 + 7 + 3), not 8 and 31. Keeping the lower figures makes the version changelog an unreliable baseline even though the current v1.1 total of 19 is correct.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Not changing this — the v1.0.0 figures are correct as written, and the same sentence says why.
The v1.0.0 changelog entry reads:
First edition. 31 entries — 8 first-party papers and artifacts, 13 third-party works, 7 practitioner and community entries, 3 ecosystem projects — of which 19 are third-party, plus 4 distribution channels. Separately recorded and not counted: the OSDI '20 paper that introduced the simulator, 4 borrowed-implementation and trace-format rows, 2 downstream algorithm adopters, and repository signals.
So §1 held 9 table rows, of which 8 were counted entries and the ninth — the OSDI '20 paper — was explicitly excluded from the total, because a project cannot be evidence of its own reach. Its Evidence cell said the same thing in the table: "Recorded as the origin, not as adoption." 8 + 13 + 7 + 3 = 31 is internally consistent; 9 + 13 + 7 + 3 = 32 would double-count the row the entry says is not counted.
The new exclusion paragraph lists all nine works because all nine are now excluded, origin row included. That is a change in what the census lists, not new evidence about what v1.0.0 counted.
Generated by Claude Code
Six parallel searches, each on a different modality, then independent re-verification of every candidate against raw source text before it was allowed into the document: - all 111 forks resolved with git ls-remote and diffed against upstream's own object graph, so a fork that merely copies an upstream branch is excluded; 56 have novel branch tips, 11 carry substantive work - ~80 public code-search queries (imports, submodules, FetchContent, binary invocations, trace-format identifiers) - the repository's own 318 issues and PRs and 7 discussions - dependency and archive graphs: ecosyste.ms across 100 registries, deps.dev, Software Heritage, DataCite, the Go module proxy - citation graphs and full text for four papers, routed around ACM/IEEE paywalls via author copies - the full 460-artifact Chameleon Trovi catalogue New: a new section for third-party forks (11 rows, the strongest being MongoDB's WiredTiger eviction emulation, plus EPFL memory-tiering work, a USTC reinforcement-learning policy, and Columbia's RingLFU); two journal papers (CAPSULE, SIGMETRICS '26; iLRU, IEEE TMC 2025); the SOSP '23 artifact-evaluation committee, which installed and ran the tool independently of the authors it was reviewing; a table of algorithms contributed from outside the project, including the whole prefetch module that the SIGMETRICS '26 paper now uses as its baselines; four more trace-format borrowers; and Apache Traffic Server. Corrections to the previous edition: - "almost all forks are dormant copies of upstream text" was wrong. The measured split is now stated, along with the reason a fork count is not a user count in either direction. - the quotation convention is now stated explicitly, because two source quotes wrap across lines and several are elided. Excluded as first-party, but recorded so a reader does not miscount them: 17 forks of student projects from the maintainer's own course, three Trovi artifacts by project co-authors, and a collaborator's npm prototype. 39 entries, all third-party. All 31 quotations carried over from the previous edition are byte-identical; anchors, repo-relative paths, commit pinning and all 109 external links re-checked. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WCUG9YH1JDDnNwWwfg8hn4
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 40cb07f25f
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| Algorithms and infrastructure given back upstream by people with no project affiliation. | ||
| Counted here rather than above, because contributing a feature is a different claim from | ||
| adopting the tool. |
There was a problem hiding this comment.
Keep contribution-only rows out of the adoption total
The headline total of 39 is obtained only by counting these five contributor rows alongside the research, fork, and practitioner tables, even though this section explicitly says contributing is a different claim from adoption and several rows provide no evidence of building, bundling, forking, distributing, or running libCacheSim as required by the scope. This inflates the census's adoption figure; report the contributor funnel separately or broaden the stated scope and label the combined total accordingly.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Correct, and fixed in da59da9. The section said contributing is a different claim from adoption and then the changelog folded those five rows into one figure of "39 entries, all third-party". Both cannot be true, and you are right about the weaker rows in particular: for the Microsoft bug fix and the Rust-bindings attempt, the contribution is the only evidence there is — no build, run, or fork of their own is shown, which is what the stated scope requires.
The total is now reported as 34 third-party adoption entries — 15 research, 11 forks, 8 practitioner and community — with the 5 outside contributions, 4 distribution channels, and 10 borrowed-implementation and downstream rows each counted separately. The contributor table's preamble now says explicitly that it is counted apart from the adoption total, and why.
I kept the table in the document rather than deleting it. One of those rows is the strongest reach signal in the census: the prefetch module (Mithril, OBL, PG) was contributed by an outside researcher over five merged PRs, and a third-party SIGMETRICS '26 paper now uses exactly those three as its baselines. That chain is worth recording — it just is not an adoption count.
Generated by Claude Code
| not an ancestor of any upstream ref; of those, eleven carry substantive third-party work and | ||
| are listed in [§2](#2-third-party-forks), seventeen are student projects from the | ||
| maintainer's course, and the remainder are stale copies of upstream branches, branches of | ||
| already-merged PRs, or editor- and doc-only edits. The fifty-five with no novel commits are | ||
| plain mirrors. A count of forks is therefore not a count of users in either direction: it | ||
| overstates adoption by a factor of ten, and it hides the forks that matter. |
There was a problem hiding this comment.
Account for separately categorized forks in the breakdown
This partitions the 56 forks with novel commits into 11 listed here, 17 course forks, and a remainder described as stale, merged, or editor/doc-only, but the document itself identifies four novel paper forks plus mbrooker/libCacheSim on lines 77–80 and another six smaller implementation or packaging forks on lines 82–86. Those forks fit none of the stated buckets, so the breakdown and ensuing claim that fork counts overstate adoption by a factor of ten are not supported; classify all 56 consistently and recalculate the ratio.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Correct on both counts, and fixed in 803564c. The buckets did not cover the forks the document itself names elsewhere, and 111 / 11 was not a defensible ratio once those groups exist.
Rather than patch the sentence, I re-measured. Every fork resolved with git ls-remote, every branch tip checked for commits reachable from none of upstream's 30 branches and 244 pull-request refs:
| group | count |
|---|---|
| substantive independent third-party work (the forks in §2) | 10 |
| smaller but genuine third-party work | 8 |
| tied to an entry counted elsewhere here, via its paper or author | 8 |
| project members, co-authors, alternate accounts | 6 |
| student projects from the maintainer's course | 14 |
| a novel tip but no novel work | 12 |
| plain mirrors, zero novel commits | 53 |
| total | 111 |
Mutually exclusive and exhaustive, checked programmatically — no fork in two groups, none unassigned. Three things that had to be fixed for it to close:
gws8820/2-Level-libCacheSimis not a fork of this repository. It appears in neither the API listing nor the 111-member network graph — it is a re-upload of the source tree. It was in my numerator, mixing two populations. Corrected separately in 9f462cb; the row stands, but it is excluded from the fork arithmetic.- 111 vs 109.
forks_countis 111 but only 109 are listable; the other two are forks of a fork. Both are included above. - Pull-request refs cut the other way. Work offered upstream as a PR is reachable from
refs/pull/*/head, so it scores zero novel commits. The GLib-removal fork lands in the 53 "mirrors" for that reason while carrying 24 commits and a header that has never existed ondevelop. The section now says this explicitly, because the measurement understates real work in exactly that case.
The ratio is now stated with its threshold attached instead of as one number: 26 of 111 carry independent third-party work, 10 of 111 carry substantive research work. The tenfold figure survives only under the strictest reading, so it is no longer presented as the headline.
Worth noting what this does to the claim in the other direction: the pre-existing sentence I was correcting said forks are "almost all dormant copies of upstream text". That was the larger error — 58 of 111 have commits upstream does not.
Generated by Claude Code
The contributor table said in its own preamble that contributing a feature is a different claim from adopting the tool, and then the changelog folded those five rows into a single headline figure of 39 "entries, all third-party". Both cannot be true, and for some of those rows the contribution is the only evidence there is — no build, run, or fork of their own is shown, which is what the stated scope requires. The total is now reported as 34 third-party adoption entries — 15 research, 11 forks, 8 practitioner and community — with the 5 outside contributions, 4 distribution channels, and 10 borrowed-implementation and downstream rows each counted separately. Reported by Codex review on 40cb07f. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WCUG9YH1JDDnNwWwfg8hn4
It is listed in the third-party forks section, but it appears in neither the API's fork listing (109 rows) nor the 111-member network graph: it is a copy of the source tree uploaded as a new repository. The row stands — it carries the full tree and its README documents the two-level extension — but calling it a fork put it in the wrong population, and it must not be counted in the fork arithmetic. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WCUG9YH1JDDnNwWwfg8hn4
The fork breakdown did not account for every diverged fork — it named 11 plus 17 course forks and swept the rest into "stale, merged, or doc-only", which left out the forks the document itself names elsewhere. The claim that a fork count "overstates adoption by a factor of ten" came from 111/11 and was unsupported once those groups exist. Re-measured from scratch rather than patched. Every fork resolved with git ls-remote, every branch tip checked for commits reachable from none of upstream's 30 branches and 244 pull-request refs: 10 substantive independent third-party work (the forks in §2) 8 smaller but genuine third-party work 8 tied to an entry counted elsewhere via its paper or author 6 project members, co-authors, alternate accounts 14 course forks 12 a novel tip but no novel work 53 plain mirrors, zero novel commits --- 111 total, mutually exclusive, verified programmatically The multiple is now stated with its threshold attached — 26 of 111 carry independent third-party work, 10 carry substantive research work — instead of one unqualified figure. Two things this measurement turned up: - Including pull-request refs makes work that was offered upstream score zero novel commits. The GLib-removal fork is a mirror by this measure and real work by any other, so the section says so rather than hiding it. - 111 is forks_count; only 109 are listable, the remaining two being forks of a fork. Both are included. Also tightened the mack-w evidence: hashmap.h is absent from develop, but it does exist in upstream's PR refs, so the claim is now that no commit on develop has ever touched that path — which is what is checkable. Reported by Codex review on 40cb07f. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WCUG9YH1JDDnNwWwfg8hn4
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 803564c854
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| | Smaller but genuine third-party work — a WATT policy, sampled LRU and SIEVE variants, a Rust MRC tool, Docker packaging, a pybind11 wrapper, a 3L-Cache ablation, a standalone driver, 2021 work on the `exec` driver | 8 | | ||
| | Tied to an entry counted elsewhere in this census, through its paper or its author | 8 | | ||
| | Project members, co-authors, and alternate accounts | 6 | | ||
| | Student projects from the maintainer's course | 14 | |
There was a problem hiding this comment.
Reconcile the course-fork count in the partition
The revised partition provides fresh evidence of a count mismatch: this row assigns 14 forks to the maintainer's course, while §2 says 17 forks carry student cs2640 competition branches and calls that the largest cluster. Because this table is presented as a complete partition of all 58 novel tips, readers cannot tell whether three course forks were omitted or placed in another category; reconcile the counts or explicitly identify the overlapping forks and their chosen bucket.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Right that it was unreconcilable as written; fixed in f9e8ed5.
Both numbers were correct and the document failed to connect them. Seventeen forks carry a cs2640 branch; only fourteen have a commit reachable from no upstream ref. The other three carry the branch with nothing of their own on it, so the partition puts them in the 53 mirrors — which is where they belong under the table's own predicate, but a reader had no way to know that rather than suspecting three forks had been dropped.
The table row now reads "14 of the 17 forks that carry a cs2640 branch; the other three carry the branch with no commits of their own, so they are counted among the 53 mirrors", and §2 says "seventeen … — fourteen with commits of their own".
The 17 is independently measured, not inherited from the partition: git ls-remote --heads over all 111 forks, grepping for the branch name.
Generated by Claude Code
| [deps.dev](https://api.deps.dev/v3alpha/systems/pypi/packages/libcachesim/versions/0.3.3:dependents) | ||
| reports `{"dependentCount":0,...}` for both the PyPI and npm packages, and |
There was a problem hiding this comment.
Link the npm reverse-dependency result
The linked deps.dev request is only for the PyPI package libcachesim at version 0.3.3, so it cannot report the claimed npm result for the separately named libcachesim-node package. Anyone auditing the no-third-party-packaging conclusion can verify only half of this assertion; add the npm package/version dependents endpoint or narrow the statement to PyPI.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Correct; fixed in f9e8ed5. I had queried both endpoints but linked only one, which left half the claim unauditable — exactly the failure this document is supposed to prevent.
Both are now linked, and the quoted response is the complete JSON both return rather than an abbreviated form:
pypi/libcachesim@0.3.3 -> {"dependentCount":0,"directDependentCount":0,"indirectDependentCount":0}
npm/libcachesim-node@0.3.2 -> {"dependentCount":0,"directDependentCount":0,"indirectDependentCount":0}
Re-checked just now against api.deps.dev/v3alpha/systems/{pypi,npm}/packages/…:dependents; byte-identical for both.
Generated by Claude Code
…ndpoints Two review findings on 803564c, both correct. The fork partition assigned 14 forks to the maintainer's course while §2 said seventeen carry a `cs2640` branch. Both numbers are right — three of the seventeen carry the branch with no commits of their own, so they fall in the 53 mirrors — but the document never said so, leaving a reader unable to tell whether three forks had been dropped or filed elsewhere. Now stated in the table row and in §2. The reverse-dependency sentence claimed deps.dev reports zero dependents for both the PyPI and the npm package but linked only the PyPI endpoint, so half the assertion was unauditable. Both endpoints are now linked, and the quoted response is the full JSON both return verbatim. Reported by Codex review on 803564c. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WCUG9YH1JDDnNwWwfg8hn4
plugin.c leaked the dlopen handle when dlsym failed. Nothing from the library is in use on that path, unlike the success path the existing comment covers, so it is closed rather than leaked. testCLI now sweeps hyperbolic, belady and beladySize, which cachesim special-cases and the registry also carries; the trace is oracleGeneral, so the Belady policies are valid on it. 174 checks becomes 180. mktemp -d is given an explicit template, since BSD mktemp rejects the bare form and the macOS job runs this target. The ctest entry gains SKIP_REGULAR_EXPRESSION, so a run that skipped itself for want of binaries or traces no longer reports as a pass. CONTRIBUTING.md described the CLI test by linking test/test_cli.sh. That file arrives in a different PR of this series, so the link would dangle for anyone merging the community files alone; the guidance now leads with what to cover and why the library tests will not catch it. adoption.md, which arrived on develop in #323, carries a BibTeX block whose % comment Pygments' bibtex lexer rejects. Harmless normally, but this branch sets fail_on_warning, so it broke the docs build; the comment moves into prose above the block. adoption.md is also added to the Sphinx toctree, which it needs to be reachable in the rendered docs. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YUq1vM4g82TkaX2jvLmuQc
What this adds
doc/adoption.md— a versioned, source-linked inventory of who, outside this project, uses libCacheSim. Every entry quotes the sentence in a primary source that supports it and links to that source. Entries without a checkable source are not listed.Three properties the document holds itself to:
raw.githubusercontent.comfor code and READMEs, arXiv HTML or publisher PDFs for papers, raw API JSON for issues — never against a rendered summary. The only alterations are closing up line breaks where a source wraps a sentence, and marking elisions with an ellipsis; both are stated in the document.Contents (v1.2.0, census date 2026-08-13)
39 entries, all third-party, plus 4 distribution channels.
@mongodb.comaddress. Also EPFL memory-tiering work behind TLB/access-bit filtering, a USTC reinforcement-learning policy with an unpublished CDN paper behind it, Columbia's RingLFU, CMU's DRAM-plus-flash hybrid, and prefetcher/eviction-interference instrumentation.Recorded but counted separately: seven projects that borrow only the trace format or an algorithm implementation (Pelikan, Caffeine, Otter, Theine, go-sieve,
djc/s3-fifo, Cache is King), and downstream SIEVE/S3-FIFO reimplementations in Ceph, Apache Traffic Server, and TiDB, labelled algorithm adoption, not libCacheSim adoption — the most likely way this census gets misread.A negative result that took a full sweep to establish: no third-party packaging exists. An exact-name lookup across the 100 registries indexed by ecosyste.ms returns exactly one row — the project's own PyPI package — and deps.dev reports zero reverse dependencies for both the PyPI and npm packages. Three near-misses are named so they are not mistaken for ports, including a Go module the proxy synthesised from the git tags that nothing imports and that cannot work, since there is no
go.mod.What changed since the first edition
git ls-remoteand diffed against upstream's own object graph; ~80 public code-search queries; the repository's own 318 issues and PRs and 7 discussions; dependency and archive graphs (ecosyste.ms, deps.dev, Software Heritage, DataCite, the Go proxy); citation graphs and full text for four papers, routed around ACM/IEEE paywalls via author copies; and the full 460-artifact Chameleon Trovi catalogue.One claim from the earlier editions was wrong and is now corrected. They said forks "are almost all dormant copies of upstream text". Measured properly, 56 of 111 have a branch tip that is not an ancestor of any upstream ref, and 11 carry substantive third-party work. The document now states the split and why a fork count is not a user count in either direction — it overstates adoption tenfold while hiding the forks that matter.
Excluded as first-party, but recorded so a reader does not miscount
17 forks carrying a
cs2640branch of student cache-competition projects — the largest single cluster in the fork graph — from a course whose instructor is the project's maintainer; three Chameleon artifacts by project co-authors; and a collaborator's npm prototype published three days before the in-tree package.Notes for review
README.md,doc/README.md, anddoc/adoption.md.cache_extTOCS extension.macos / clangwas red for most of this PR's life for a reason unrelated to it — a pre-existing-Werrorbreak ondevelopfrom Xcode 26.6's-Wimplicit-const-int-float-conversionfiring on twoUINT64_MAX → doubleconversions inmrcProfiler.cpp. That was diagnosed in this thread, fixed ondevelopby fix: avoid inexact UINT64_MAX to double conversion in mrcProfiler #325, anddevelophas since been merged in.CITATION.cffand mint a DOI. A third-party fork already has a Zenodo DOI while upstream does not, and one surveyed paper miscites the software to unrelated authors at a repository that does not exist — which is also why this census is built from full text and code rather than reference lists.🤖 Generated with Claude Code
https://claude.ai/code/session_01WCUG9YH1JDDnNwWwfg8hn4