# 2025-02-19

## Action items

* Review https://github.com/salsa-rs/salsa/pull/602
* micha to review
* Review https://github.com/salsa-rs/salsa/pull/695
* Review https://github.com/salsa-rs/salsa/pull/603
* nikomatsakis
* Review https://github.com/salsa-rs/salsa/pull/677
* Review https://github.com/salsa-rs/salsa/pull/685
* Review https://github.com/salsa-rs/salsa/pull/687
* Review https://github.com/salsa-rs/salsa/pull/649
* Review https://github.com/salsa-rs/salsa/pull/658

## Notes

* Merged the tracked by default
* Query return types have to be Update by default
* GC first step is ready for review
* https://github.com/salsa-rs/salsa/pull/602
* ready for review
* Performance improvement around ArcSwap
* Because of the "deferred collection" queue we don't need ArcSwap ref counting
* https://github.com/salsa-rs/salsa/pull/695
* Tests for fixed point cycle checking is passing
* 2-3% regression
* awaiting review
* https://github.com/salsa-rs/salsa/pull/603
* issues:
* peak memory, can't hold on to the ASTs for all files for an entire revision
* need to start collecting them
* persistent caching
* we may want to have a way to drop LRU values during the `&`-revision
* we could do that for fields where we don't release `&mut`
* rust-analyzer
* swapped out boxcar which is loom tested :huzzah:
* https://github.com/salsa-rs/salsa/pull/688
* small regression
* https://github.com/salsa-rs/salsa/pull/696 may help
* supertype impl is good
* https://github.com/salsa-rs/salsa/pull/677 ready for review, regression of ~10% in some benchmarks.
* Threshold can be changed here https://codspeed.io/salsa-rs/salsa/settings
* lukas has made changes related to LRU that are good
* something "unwind"
* modified the debug code to be impl'd on ingredient or something or other :)
* would have to walk the pages for the struct type that it takes as input
* and then find those that have memos attached
* and dump that data out
* Carl to share some of the code around that
* Post-meeting notes with Carl:
*
* porting over to loom: some progress made
* but not high priority given that parallelism isn't top priority yet
* on 602
* we have a reset method to recycle an interned slot and mark it as outdated, but how should it be exposed
* feature flag: `salsa_unstable`, `#[doc(hidden)]`
- Top priority for Niko:
- release workflow: https://github.com/salsa-rs/salsa/pull/658
- Release a 1.0-alpha-1
- Serialization:
- Design doc: https://hackmd.io/pFbiXVsuTTK4pakI___MTA
- As long as everything is reachable from a serialized struct in a storage-marked `serializable` list, we can (de)serialize everything. we do a walk, and load/unload from a list. if it's not in a list, assert/panic/skip /whatever.
- implementation: https://github.com/nikomatsakis/salsa/tree/serialization

---

## Dumping fn contents

(post-meeting notes with Carl Meyer)

Usage:

fn dump(db: &dyn Db) {
    let definition_ingredient = Definition::ingredient(db);
    for (id, def) in definition_ingredient.entries(db) {
        let database_key_index = definition_ingredient.database_key_index(Definition(id));
        eprintln!("{database_key_index:?}");
        dbg!(def);
        let memos = def.my_memos();
        let memo = memos.get(salsa::MemoIngredientIndex::from_usize(0));
        dbg!(memo);
    }

    let use_ingredient = Use::ingredient(db);
    for (id, u) in use_ingredient.entries(db) {
        let database_key_index = use_ingredient.database_key_index(Use(id));
        eprintln!("{database_key_index:?}");
        dbg!(u);
        let memos = u.my_memos();
    }
}

Every ingredient (tracked/interned/input) has a memo table associated with it. look at `MemoTable::into_memos` (but with `&self`) is what we might want.

`MemoIngredientIndex`es are accociated with tracked functions. extra args creates an interned struct for extra args. we're currying all arguments into a single salsa struct.

1. All tracked functions take exactly one ingredient (input, interned struct, tracked struct) as argument. If it takes more than one, they are interned, and we are back to one argument). We effectively *curry* all extra arguments to a tracked function into a single Salsa ingredient.
2. Every tracked function has a `memo_ingredient_index`.
3. Every ingredient has a MemoTable, which stores at each index possibly a memoized return value for the tracked function with that `memo_ingredient_index`.
4. So if we have a tracked struct `File` and two tracked functions `read_contents` and `stat_file`, which both take a `File` as argument. Assume `read_contents` has `memo_ingredient_index` `0` and `stat_file` has `memo_ingredient_index` `1`. Then each distinct `File` will have its own `MemoTable`, within which index `0` would possibly store a memo with the cached return value of `read_contents` when given that `File` as argument, and index `1` would possibly store a memo with the cached return value of `stat_file` when given that `File` as argument.
- Put differently: a tracked function's return value will be stored in the tracked fn *input* ingredient's `MemoTable`. "Input" refers to *any* Salsa ingredient (e.g., `#[salsa::tracked]`, `#[salsa::input]`, `#[salsa::interned]` structs), not just input structs.

If you want to find all memoized return values for a tracked function (say `read_contents`), you need to note down the `memo_ingredient_index` of `read_contents`, then go iterate through all `File` objects in the db (all instances of whatever ingredient the tracked function takes as argument), and for each one, find the memo in its MemoTable at the `memo_ingredient_index` of `read_contents`.