loom
loom copied to clipboard
tokio-rs
Allocate runtime objects in a bump arena
Main changes:
- To deal with the lifetime requirements
Executionis now re-created for each iteration (onlyPathis created once in the beginning). - Every bump-allocated object now has a lifetime which can be annoying :(
-
CausalCellstate is moved to the objectStore.
Apart from that the changes are mostly mechanical.
The remaining big source of periodic allocations is https://github.com/tokio-rs/loom/blob/3fb6e6efb4403c14ce7963b5b7f6574710153440/src/sync/atomic/atomic.rs#L12 but it doesn't seem worth the effort to move it inside the object::Store.
Again using tokio executor loom tests as a benchmark (LOOM_MAX_PREEMPTIONS=2 RUSTFLAGS="--cfg loom" cargo test --release --lib in the tokio/tokio-executor dir), execution time went down from 15.2s to 10.9s compared to master 🎉
Sorry for the delay in reviewing this! I can continue reviewing if you'd like and you're interested in continuing working on this.
Since most of the TODOs are now resolvable and there aren't any conflicts I think this is in a near-mergable stage.
@davidbarsky Sure 👍 Definitely interested in merging this. I am traveling right now, so I will update the code next week.
Sorry for the delay.
I have been playing with some other refactors using the execution's object store, and I came to the realization that we could leverage that object store as a "safer" bump allocator. Instead of doing "allocations" we store an enum of all possible types we want to track in the object store.
work is here: https://github.com/tokio-rs/loom/tree/exp
If it pans out, it may supersede this PR. I will update as I figure things out.
Sorry for the delay.
I have been playing with some other refactors using the execution's object store, and I came to the realization that we could leverage that object store as a "safer" bump allocator. Instead of doing "allocations" we store an enum of all possible types we want to track in the object store.
work is here: https://github.com/tokio-rs/loom/tree/exp
If it pans out, it may supersede this PR. I will update as I figure things out.
Ok, I've updated the PR nevertheless.
88e4225b4e9e88d0f050cd7061d8e7bc02d16d35 was merged and probably superseded this.
