Unchecked page access

[ibraheemdev]

Interested to see the performance results...

[netlify]

✅ Deploy Preview for salsa-rs canceled.

Name	Link
🔨 Latest commit	950eb1a
🔍 Latest deploy log	https://app.netlify.com/projects/salsa-rs/deploys/683a508314b9ff000869ac99

[codspeed-hq]

CodSpeed Performance Report

Merging #887 will improve performances by 16.45%

_{Comparing ibraheemdev:ibraheem/page-access (950eb1a) with master (8aaeb70)}

Summary

⚡ 1 improvements
✅ 11 untouched benchmarks

Benchmarks breakdown

	Benchmark	BASE	HEAD	Change
⚡	many_tracked_structs	37.8 µs	32.5 µs	+16.45%

[Veykril]

I assume this is not doable for the same reason we cannot ever omit the type checks, someone could smuggle an index from one database to another. The type checks are a lot more expensive, I'd love if we could get rid of them

[ibraheemdev]

Maybe an (unsound) feature flag with the invariant that your application only has a single database? Or maybe we could even have a global that panics if you try to create multiple databases?

[Veykril]

That (panic on DB creation) does sound like a possible escape, that should also allow dropping the nonce check in that situation I think? Testing that seems a bit iffy though.

Now I wonder if there is a design where we could brand databases with an invariant lifetime given we already have a lifetime infestation everywhere anyways (though that one is currently covariant due to being the references lifetime). That could prevent smuggling as well? Though that won't avoid the nonce check, given the static caching system (I am not a fan of this honestly, but I can't think of a better way either)

[ibraheemdev]

I assume this is not doable for the same reason we cannot ever omit the type checks, someone could smuggle an index from one database to another. The type checks are a lot more expensive, I'd love if we could get rid of them

Actually, how is this possible given the nonce check? That guarantees we have the same database whose index we cached.

With inventory now the ingredient indices and types are stable, so the safety argument is clearer I think.

[ibraheemdev]

Opened #937. I think you're right that we can't do this for slots at least, because slot IDs don't encode the database they were created from.