Trait AllocationTracker

pub trait AllocationTracker {
    // Required methods
    fn allocated(
        &self,
        addr: usize,
        object_size: usize,
        wrapped_size: usize,
        group_id: AllocationGroupId,
    );
    fn deallocated(
        &self,
        addr: usize,
        object_size: usize,
        wrapped_size: usize,
        source_group_id: AllocationGroupId,
        current_group_id: AllocationGroupId,
    );
}

Tracks allocations and deallocations.

Required Methods

fn allocated( &self, addr: usize, object_size: usize, wrapped_size: usize, group_id: AllocationGroupId, )

Tracks when an allocation has occurred.

All allocations/deallocations that occur within the call to AllocationTracker::allocated are ignored, so implementors can allocate/deallocate without risk of reentrancy bugs. It does mean, however, that the allocations/deallocations that occur will be effectively lost, so implementors should ensure that the only data they deallocate in the tracker is data that was similarly allocated, and vise versa.

As the allocator will customize the layout to include the group ID which owns an allocation, we provide two sizes: the object size and the wrapped size. The object size is the original layout of the allocation, and is valid against the given object address. The wrapped size is the true size of the underlying allocation that is made, and represents the actual memory usage for the given allocation.

fn deallocated( &self, addr: usize, object_size: usize, wrapped_size: usize, source_group_id: AllocationGroupId, current_group_id: AllocationGroupId, )

Tracks when a deallocation has occurred.

source_group_id contains the group ID where the given allocation originated from, while current_group_id is the current group ID, and as such, these values may differ depending on how values have had their ownership transferred.

All allocations/deallocations that occur within the call to AllocationTracker::deallocated are ignored, so implementors can allocate/deallocate without risk of reentrancy bugs. It does mean, however, that the allocations/deallocations that occur will be effectively lost, so implementors should ensure that the only data they deallocate in the tracker is data that was similarly allocated, and vise versa.

As the allocator will customize the layout to include the group ID which owns an allocation, we provide two sizes: the object size and the wrapped size. The object size is the original layout of the allocation, and is valid against the given object address. The wrapped size is the true size of the underlying allocation that is made, and represents the actual memory usage for the given allocation.

Implementors