Currently, Guard::flush only succeeds if there are enough entries in the local buffer to be used as reclamation nodes for any active threads. In cases where there are high priority large objects, users may want to force flush the buffer even if there are not enough entries. We can expose Guard::force_flush that does this by allocating nodes on-demand to perform the reclamation, or potentially estimating the number of active threads and allocating a single buffer to serve as multiple nodes (though this seems tricky, and might be left for a future optimization). Though allocating to perform a flush sounds counterintuitive, this allocation will likely be very small compared to the memory that needs to be reclaimed, and is worth it if large objects are retired infrequently.
Currently,
Guard::flushonly succeeds if there are enough entries in the local buffer to be used as reclamation nodes for any active threads. In cases where there are high priority large objects, users may want to force flush the buffer even if there are not enough entries. We can exposeGuard::force_flushthat does this by allocating nodes on-demand to perform the reclamation, or potentially estimating the number of active threads and allocating a single buffer to serve as multiple nodes (though this seems tricky, and might be left for a future optimization). Though allocating to perform a flush sounds counterintuitive, this allocation will likely be very small compared to the memory that needs to be reclaimed, and is worth it if large objects are retired infrequently.