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 canceled.

Name	Link
🔨 Latest commit	c6077c4
🔍 Latest deploy log	https://app.netlify.com/sites/salsa-rs/deploys/672886d84f15ed0008fdc67f

[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.

[MichaReiser]

Nit

Suggested change

	let dependency_index = database_key_index;
	if !zalsa_local.is_output_of_active_query(dependency_index) {
	if !zalsa_local.is_output_of_active_query(database_key_index) {

[MichaReiser]

Suggested change

	// The revision the value was first interned in.
	first_interned_at: Revision,
	// The most recent interned revision.
	last_interned_at: AtomicRevision,
	/// The revision the value was first interned in.
	first_interned_at: Revision,
	/// The most recent interned revision.
	last_interned_at: AtomicRevision,

[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.

[MichaReiser]

I already discussed this with @ibraheemdev but I document it here in case anyone else ends up reviewing this PR or tries to fix the failing test.

The fix here is to always set last_interned_at even then the first_interned_at is equal to revision

Suggested change

	if value.first_interned_at > revision {
	// The slot was reused.
	return true;
	}
	if value.first_interned_at < revision {
	// The slot is valid in this revision but we have to sync the value's revision.
	value.last_interned_at.store(db.zalsa().current_revision());
	}
	if value.first_interned_at > revision {
	// The slot was reused.
	true
	} else {
	// The slot is valid in this revision but we have to sync the value's revision.
	value.last_interned_at.store(db.zalsa().current_revision());
	false
	}