Struct solana_runtime::account_storage::AccountStorage

pub struct AccountStorage {
    map: AccountStorageMap,
    shrink_in_progress_map: DashMap<Slot, Arc<AccountStorageEntry>>,
}

Fields

map: AccountStorageMap

map from Slot -> the single append vec for the slot

shrink_in_progress_map: DashMap<Slot, Arc<AccountStorageEntry>>

while shrink is operating on a slot, there can be 2 append vecs active for that slot Once the index has been updated to only refer to the new append vec, the single entry for the slot in ‘map’ can be updated. Entries in ‘shrink_in_progress_map’ can be found by ‘get_account_storage_entry’

Implementations

impl AccountStorage

pub(crate) fn get_account_storage_entry( &self, slot: Slot, store_id: AppendVecId ) -> Option<Arc<AccountStorageEntry>>

Return the append vec in ‘slot’ and with id=‘store_id’. can look in ‘map’ and ‘shrink_in_progress_map’ to find the specified append vec when shrinking begins, shrinking_in_progress is called. This fn looks in ‘map’ first, then in ‘shrink_in_progress_map’, then in ‘map’ again because ‘shrinking_in_progress’ first inserts the new append vec into ‘shrink_in_progress_map’ Then, when ‘shrink_in_progress’ is dropped, the old append vec is replaced in ‘map’ with the new append vec then the new append vec is dropped from ‘shrink_in_progress_map’. So, it is possible for a race with this fn and dropping ‘shrink_in_progress’. Callers to this function have 2 choices:

1. hold the account index read lock for the pubkey so that the account index entry cannot be changed prior to or during this call. (scans do this)
2. expect to be ready to start over and read the index again if this function returns None Operations like shrinking or write cache flushing may have updated the index between when the caller read the index and called this function to load from the append vec specified in the index. In practice, this fn will return the entry from the map in the very first lookup unless a shrink is in progress. The third lookup will only be called if a requesting thread exactly interposes itself between the 2 map manipulations in the drop of ‘shrink_in_progress’.

pub(crate) fn assert_no_shrink_in_progress(&self)

assert if shrink in progress is active

pub(crate) fn get_slot_storage_entry( &self, slot: Slot ) -> Option<Arc<AccountStorageEntry>>

return the append vec for ‘slot’ if it exists This is only ever called when shrink is not possibly running and there is a max of 1 append vec per slot.

pub(crate) fn get_slot_storage_entry_shrinking_in_progress_ok( &self, slot: Slot ) -> Option<Arc<AccountStorageEntry>>

return the append vec for ‘slot’ if it exists

pub(crate) fn all_slots(&self) -> Vec<Slot>

pub(crate) fn initialize(&mut self, all_storages: AccountStorageMap)

initialize the storage map to ‘all_storages’

pub(crate) fn remove( &self, slot: &Slot, shrink_can_be_active: bool ) -> Option<Arc<AccountStorageEntry>>

remove the append vec at ‘slot’ returns the current contents

pub(crate) fn iter(&self) -> AccountStorageIter<'_>

iterate through all (slot, append-vec)

pub(crate) fn insert(&self, slot: Slot, store: Arc<AccountStorageEntry>)

pub(crate) fn shrinking_in_progress( &self, slot: Slot, new_store: Arc<AccountStorageEntry> ) -> ShrinkInProgress<'_>

called when shrinking begins on a slot and append vec. When ‘ShrinkInProgress’ is dropped by caller, the old store will be replaced with ‘new_store’ in the storage map. Fails if there are no existing stores at the slot. ‘new_store’ will be replacing the current store at ‘slot’ in ‘map’ So, insert ‘new_store’ into ‘shrink_in_progress_map’. This allows tx processing loads to find the items in ‘shrink_in_progress_map’ after the index is updated and item is now located in ‘new_store’.

Trait Implementations

impl Debug for AccountStorage

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl Default for AccountStorage

fn default() -> AccountStorage

Returns the “default value” for a type.