On Mon, Apr 14, 2014 at 10:32 PM, Daniel Micay <[email protected]>wrote:
> 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. > By the way, do you have any idea how this is going to pan out on processors like the Mill CPU where the address space is shared among processes ? > > > 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. > >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
