On 14/04/14 12:41 PM, Matthieu Monrocq wrote: > Memory fragmentation is a potential issue in all languages that not use > a Compacting GC, so yes.
It's much less of an issue than people make it out to be on 32-bit, and it's a non-issue on 64-bit with a good allocator (jemalloc, tcmalloc). Small dynamic memory allocations are tightly packed in arenas, with a very low upper bound on fragmentation and metadata overhead. At a certain cutoff point, allocations begin to fall through directly to mmap instead of using the arenas. On 64-bit, the address space is enormous so fragmenting it is only a problem when it comes to causing TLB misses. > There are some attenuating circumstances in Rust, notably the fact that > unless you use a ~ pointer the memory is allocated in a task private > heap which is entirely recycled at the death of the task, but memory > fragmentation is always a potential issue. All dynamic memory allocations are currently done with the malloc family of functions, whether you use sendable types like `Vec<T>`, `Arc<T>` and `~T` or task-local types like `Rc<T>`. Using a task-local heap for types like `Rc<T>` would only serve to *increase* the level of fragmentation by splitting it up more. For example, jemalloc implements thread-local caching, and then distributes the remaining workload across a fixed number of arenas. Increasing the level of thread-local caching has a performance benefit but by definition increases the level of fragmentation due to more unused capacity assigned to specific threads.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
