Struct miri::alloc_addresses::reuse_pool::ReusePool
source · pub struct ReusePool {
address_reuse_rate: f64,
address_reuse_cross_thread_rate: f64,
pool: Vec<Vec<(u64, Size, ThreadId, VClock)>>,
}
Expand description
The pool strikes a balance between exploring more possible executions and making it more likely to find bugs. The hypothesis is that bugs are more likely to occur when reuse happens for allocations with the same layout, since that can trigger e.g. ABA issues in a concurrent data structure. Therefore we only reuse allocations when size and alignment match exactly.
Fields§
§address_reuse_rate: f64
§address_reuse_cross_thread_rate: f64
§pool: Vec<Vec<(u64, Size, ThreadId, VClock)>>
The i-th element in pool
stores allocations of alignment 2^i
. We store these reusable
allocations as address-size pairs, the list must be sorted by the size and then the thread ID.
Each of these maps has at most MAX_POOL_SIZE elements, and since alignment is limited to less than 64 different possible value, that bounds the overall size of the pool.
We also store the ID and the data-race clock of the thread that donated this pool element, to ensure synchronization with the thread that picks up this address.
Implementations§
source§impl ReusePool
impl ReusePool
Trait Implementations§
Auto Trait Implementations§
impl Freeze for ReusePool
impl RefUnwindSafe for ReusePool
impl !Send for ReusePool
impl !Sync for ReusePool
impl Unpin for ReusePool
impl UnwindSafe for ReusePool
Blanket Implementations§
source§impl<T> BorrowMut<T> for Twhere
T: ?Sized,
impl<T> BorrowMut<T> for Twhere
T: ?Sized,
source§fn borrow_mut(&mut self) -> &mut T
fn borrow_mut(&mut self) -> &mut T
Layout§
Note: Most layout information is completely unstable and may even differ between compilations. The only exception is types with certain repr(...)
attributes. Please see the Rust Reference's “Type Layout” chapter for details on type layout guarantees.
Size: 40 bytes