fix(engine): flatten storage cache

[Rjected]

This fixes memory growth caused by growing execution caches, an alternative to #18879

This instead removes the cache hierarchy, so cache updates are always picked up by the moka weigher.

Previous memory usage:

New memory usage:

This also has slightly higher cache hitrate than #18879

[mattsse]

makes sense, let's go with this

I'm a bit concerned about the invalidate impl

[mattsse]

right, we can't really nest caches because this would mean that the weigher of the storage_cache would only consider new acc -> storage entries

this is better because it treats storage slots as individual entries, which I guess explains the higher hit rate

we likely have additional address overhead, but this should be okay, we could compress this to a u64 with a separate map, like we do in the pool, but perhaps not that useful

[mattsse]

hmm, unsure this is sound because this feels problematic

dashmap iter

Locking behaviour: May deadlock if called when holding a mutable reference into the map.

and cache iter:

Locking behavior
This iterator relies on the iterator of dashmap::DashMap , which employs read-write locks. May deadlock if the thread holding an iterator attempts to update the cache.

tho I don't know if this is applicable here
unfortunately we don't have a retain here

should be perhaps collect then remove?

[Rjected]

hmm, yeah I think we should collect then remove here

[Rjected]

this now collects

[mattsse]

we should document this with a one liner because this is a prime candidate for a bot "optimization" pr that would look perfectly valid

[mattsse]

we should document this with a one liner because this is a prime candidate for a bot "optimization" pr that would look perfectly valid