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
This was suggested a long time ago in #14, but although efficiency was mentioned as one of the motivations, the implementation just calls memset without making use of any potentially faster platform APIs.
I think these should be added since they can be efficiently implemented with the mremap system call on Linux. mremap allows you to move/grow/shrink a memory mapping, and any new pages added for growth are guaranteed to be zeroed.
Unfortunately for unix platforms, we're forwarding to libc whose realloc() doesn't support zeroing. But Windows HeapReAlloc does have HEAP_ZERO_MEMORY, and we're already using that for alloc_zeroed. So why not realloc_zeroed?
This was suggested a long time ago in #14, but although efficiency was mentioned as one of the motivations, the implementation just calls
memset
without making use of any potentially faster platform APIs.Unfortunately for unix platforms, we're forwarding to
libc
whoserealloc()
doesn't support zeroing. But WindowsHeapReAlloc
does haveHEAP_ZERO_MEMORY
, and we're already using that foralloc_zeroed
. So why notrealloc_zeroed
?Here's my proof-of-concept: https://github.com/andylizi/rust/commits/realloc-zeroed
The text was updated successfully, but these errors were encountered: