You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The problem/use-case that the feature addresses
Current defrag implementation uses explicit allocatorDefragAlloc/allocatorDefragFree functions that bypass tcache. The motivation to bypass tcache is so that when we free a memory ptr because of defrag we want to avoid reallocating it from tcache in next allocation, bypassing the tcache frees the ptr directly to the arena.
The dedicated API for defrag alloc introduce a challange for modules where we do not have full control over the memory allocations (and we might not want to have this control).
In these cases we would want, ideally, to defrag by just reallocating the object(if that's required).
The proposal is to achieve this by embedding the special defrag specific allocatorDefragAlloc/allocatorDefragFree API into the zmalloc zmalloc\zfree api for the defragging thread(s).
To achieve this we would need to introduce zmalloc_thread_start_defrag() and zmalloc_thread_stop_defrag(). These would be called on begin\end of defrag cycle and when started, the zmalloc\zfree of the defrag thread would use the allocatorDefragAlloc/allocatorDefragFree instead of the normal alloc.
Alternatives you've considered
Other alternative is to give modules access to allocatorDefragAlloc/allocatorDefragFree
Additional information
This feature can be combined with additional improvement to utilize user defined tcache, to keep some of the performance benefit of tcache during defrag while keeping the alloc-free separation (force ptrs recycle through the arena before realloc)
The text was updated successfully, but these errors were encountered:
zvi-code
changed the title
[NEW] Global handling for reallocations during defrag cycle
[NEW] Defrag - Global handling for reallocations during defrag cycle
Nov 27, 2024
The problem/use-case that the feature addresses
Current defrag implementation uses explicit
allocatorDefragAlloc
/allocatorDefragFree
functions that bypass tcache. The motivation to bypass tcache is so that when we free a memory ptr because of defrag we want to avoid reallocating it from tcache in next allocation, bypassing the tcache frees the ptr directly to the arena.The dedicated API for defrag alloc introduce a challange for modules where we do not have full control over the memory allocations (and we might not want to have this control).
In these cases we would want, ideally, to defrag by just reallocating the object(if that's required).
raised in the context of the discussion #1210 (comment)
Description of the feature
The proposal is to achieve this by embedding the special defrag specific
allocatorDefragAlloc
/allocatorDefragFree
API into the zmalloc zmalloc\zfree api for the defragging thread(s).To achieve this we would need to introduce
zmalloc_thread_start_defrag()
andzmalloc_thread_stop_defrag()
. These would be called on begin\end of defrag cycle and when started, the zmalloc\zfree of the defrag thread would use theallocatorDefragAlloc
/allocatorDefragFree
instead of the normal alloc.Alternatives you've considered
Other alternative is to give modules access to
allocatorDefragAlloc
/allocatorDefragFree
Additional information
This feature can be combined with additional improvement to utilize user defined tcache, to keep some of the performance benefit of tcache during defrag while keeping the alloc-free separation (force ptrs recycle through the arena before realloc)
The text was updated successfully, but these errors were encountered: