WTinyLFU: Evict main_cache_victim when victim from window cache wins

[manitofigh]

From #162.
I tested some pre/post miss ration comparisons (txt/vscsi/oracle):
The miss ratios are identical for txt (0.4373 vs 0.4373) and vscsi (same).
For oracle, develop is 0.8246 and this branch is 0.8233 (tiny improvement of -0.0013).

[gemini-code-assist]

Summary of Changes

Hello @manitofigh, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request addresses a subtle oversight in the WTinyLFU eviction policy by ensuring that the evicted flag is properly updated when an object from the window cache successfully replaces an item in the main cache. This change aims to improve the precision of eviction tracking within the cache simulation, which has shown minor positive impacts on miss ratios for specific workloads.

Highlights

• WTinyLFU Eviction Logic: The evicted flag is now correctly set to true when an object from the window cache wins the eviction battle and is subsequently admitted into the main cache. This ensures accurate tracking of eviction events within the WTinyLFU algorithm.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request correctly fixes a bug in the WTinyLFU_evict function. When a victim from the window cache has a higher frequency than a victim from the main cache, an eviction from the main cache occurs, and the window victim is promoted. Previously, the evicted flag was not set in this scenario, which could lead to an infinite loop or multiple evictions. By adding evicted = true;, this change ensures the eviction loop terminates correctly. The fix is sound and improves the correctness of the W-TinyLFU implementation. While reviewing this function, I noticed another potential issue. In the case where the main cache has enough space to admit an object from the window cache (lines 278-290), the object is moved, but no space is freed in the overall cache system, and the evicted flag is not set. Since WTinyLFU_evict is called in a loop by cache_get_base to free up space, this could lead to an infinite loop. I recommend investigating this as a potential critical bug in a follow-up.

[1a1a11a]

Can you evaluate on more traces (https://ftp.pdl.cmu.edu/pub/datasets/twemcacheWorkload/.priv/) We can provide testbed if needed

[manitofigh]

Sure, can you please share what is necessary (creds/testbed)? Please let me know if you have any specific config (cache size, obj size, req format, etc) in mind also.

[1a1a11a]

can you join https://cloudlab.us project cs2460
I usually use cache size 0.001,0.01,0.1, ignore object size

[manitofigh]

For some reason upon requesting to join, it gives the err "No such project. Did you spell it properly?"

[1a1a11a]

Sorry it should be cs2640

[manitofigh]

Thanks for the approval; for some reason however, the website is still showing

Thank you! Stay tuned for email notifying you that your account has been activated.

when I attempt to login. Still waiting on them to activate my account.

[1a1a11a]

It should not happen. Try again? Juncheng

…

On Thu, Feb 5, 2026 at 8:59 PM Mani Tofigh ***@***.***> wrote: *manitofigh* left a comment (1a1a11a/libCacheSim#297) <#297 (comment)> Thanks for the approval; for some reason however, the website is still showing: Thank you! Stay tuned for email notifying you that your account has been activated. Once I attempt to login. Still waiting on them to activate my account. — Reply to this email directly, view it on GitHub <#297 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACBP4T4EZID7HP3N3LAVMQD4KPYQTAVCNFSM6AAAAACSSP3KQWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTQNJXGQZDMOJTGU> . You are receiving this because you commented.Message ID: ***@***.***>

[manitofigh]

I did try clearing the cache also. Still the same. I saw the approval on your end, though this seems to be on CloudLab's end.