Enable Garbage Collection for Interned Values

[ibraheemdev]

Per the mentoring instructions in #597.

Still needs some tests. Note this does not actually implement garbage collection but adds the necessary plumbing to do so.

[netlify]

✅ Deploy Preview for salsa-rs ready!

Name	Link
🔨 Latest commit	6505453
🔍 Latest deploy log	https://app.netlify.com/sites/salsa-rs/deploys/67831f78d0a26e0008a986ca
😎 Deploy Preview	https://deploy-preview-602--salsa-rs.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[codspeed-hq]

CodSpeed Performance Report

Merging #602 will not alter performance

_{Comparing ibraheemdev:gc (db71a89) with master (254c749)}

Summary

✅ 8 untouched benchmarks

[MichaReiser]

Nice. This looks good to me after adding a few tests.

[nikomatsakis]

Yes, looks good to me!

[nikomatsakis]

I see there is a test failure....have you investigated it at all?

[nikomatsakis]

My hunch is that the test is testing behavior that's not relevant anymore but I can look.

[ibraheemdev]

@nikomatsakis I'm also hitting the assertion error in this example:

#[salsa::tracked]
fn function<'db>(db: &'db dyn Database, input: Input) -> Interned<'db> {
    Interned::new(db, 0)
}

let input = Input::new(&db, 0);
function(&db, input);
input.set_field1(&mut db).to(1);
function(&db, input);

The function does not read the input so the interned value is memoized, meaning it is not re-interned in R2. What should be done in this case (and the similar failing test)?

I'm also a little unclear about the testing instructions. Should I add a log event for when values are re-interned, or is there another way I can test that? I'm also not sure how to access the reset method that I added in tests.

[MichaReiser]

I'm also a little unclear about the testing instructions. Should I add a log event for when values are re-interned, or is there another way I can test that?

That would sound reasonable to me, similar to the backdate event. We could also consider adding an event when a value is garbage collected.

[MichaReiser]

If I understand it correctly the problem is that interned ingredients created outside of a query are never revalidated because there's no corresponding query that creates them.

I see two options:

1. We forbid creating interned values outside of queries. That would match the behavior with tracked structs. The downside is that it technically becomes impossible to call a root salsa query with more than one argument because multi-argument functions intern the arguments (outside the query).
2. We disable garbage collection for ingredients created outside of queries because salsa can't track their creation. Salsa has to consider them as always referenced. That's a bit of a footgun but probably fine?

[MichaReiser]

I took a closer look at test_leaked_inputs_ignored and this is a slightly different variation of the above problem in the sense that the multi-argument-query is called as part of another query, but said query never re-executes and id_to_input panics.

I think the problem here is that function::maybe_changed_after never calls id_to_input when it short-circuits where it probably should, to at least mark the input still as used. However, it's unclear to me how that would work when the query using an interner is deeper in the tree (but the outermost query short-circuits, e.g. because the durability is higher)

[nikomatsakis]

We had a brief discussion in our meeting today--- @ibraheemdev I think values that are interned outside of any salsa query have to be concerned immortal.

[ibraheemdev]

The test_leaked_inputs_ignored test is now passing, but I added a test that still fails.

This one seems trickier. The query does not have a dependency on its input. However, changing the input still causes the database revision to be advanced. I'm not exactly sure why, but I believe the second query call only performs a shallow memoization check, meaning that maybe_changed_after is never called for the interned value, so it's revision is never updated, and the read panics.

[ibraheemdev]

Just making sure, is current_revision the correct argument to pass here?

[MichaReiser]

Oh this is interesting. I have to take a closer look. We probably have a similar problem for when the input has a higher durability and Salsa skips the deep verification because of it.