35 ms·

Just out of curiosity, how many rust users have run into memory fragmentation problems with long running processes? I love the performance and low memory profil

Just out of curiosity, how many rust users have run into memory fragmentation problems with long running processes? I love the performance and low memory profile of deterministic/static memory allocation, but without a compactor, I can't see it turning out well with long running processes. Has it turned out to be a problem in practice?

logophobia 8y ago
Isn't that one of the reasons rust compiles with JEMalloc? Fragmentation avoidance is one of its main features. Otherwise, using arenas or other strategies work very well for avoiding fragmentation. I generally haven't run into issues, mainly because rust allows me to use a lot less memory which helps. Rust code also has less dynamic memory allocation in general. You allocate for dynamically sized datastructures and long-lived data, but not like c# or java where each non-value class type is allocated on the heap (unless the compiler is smart enough to use escape analysis).
CoolGuySteve 8y ago
What purpose does compaction serve in a 64 bit virtual address space on Intel? The processor addresses and caches by cache line and the address space is huge enough to handle most allocations. Not to say it’s impossible in C/C++, but I’ve only ever seen fragmentation issues in old versions of Java and C# where the runtime repeatedly commits large swathes of contiguous memory. The key differentiator here is the VM’s insistence on contiguous allocations, whereas malloc has no such requirements.
kibwen 8y ago
It's a good question. As others have noted, jemalloc attempts to mitigate fragmentation, but you can't ever compact in a language where you can hand out pointers willy-nilly, so you would expect fragmentation to strictly increase as uptime approaches infinity. That said, Rust code doesn't tend to be especially allocation-heavy in the first place, and repeatedly allocating/freeing in a hot loop is already something that tends to be avoided as a core tenet of performance tuning, so allocator traffic may not be very heavy in the first place. I don't have any long-running Rust code myself, but I do know people who have had Rust servers that have been running for upwards of six months and they seem to be pleased at both how little memory it consumes and at how reliable it's been (you don't ever get tremendous uptime if your code isn't robust in the first place :P ).
- steveklabnik 8y ago
  Mostly, what I’ve heard about long-running processes is that, if they don’t have a leak somewhere, they tend to be pretty stable, so compaction isn’t a huge issue.
- saosebastiao 8y ago
  I'm definitely sympathetic to the argument that by avoiding allocation in the first place that you don't have to worry as much about memory profile. I allocate and destroy a bunch of arrays in my code (~100MB every minute), so it's not huge but definitely quite a few pages every time it happens. And so far I've got one process that's been running for 6 months. For the most part, whenever I get new data, I take a slice of an old array and append the new data to it to create a new array. It's fast enough, but more importantly it's just so much easier to do it that way and with a compacting GC I don't have to worry about anything. Of course I don't know how good jemalloc is at avoiding fragmentation, and I don't have the time to rewrite my code (maybe enough time to simulate, not sure). But my code creates a ton of fragment-y garbage, and I would imagine that with Rust I would end up not just translating my code, but changing semantics to mutate in place, just to avoid fragmentation. I guess maybe /r/rust would be the place to ask.

logophobia 8y ago

Isn't that one of the reasons rust compiles with JEMalloc? Fragmentation avoidance is one of its main features. Otherwise, using arenas or other strategies work very well for avoiding fragmentation. I generally haven't run into issues, mainly because rust allows me to use a lot less memory which helps. Rust code also has less dynamic memory allocation in general. You allocate for dynamically sized datastructures and long-lived data, but not like c# or java where each non-value class type is allocated on the heap (unless the compiler is smart enough to use escape analysis).

CoolGuySteve 8y ago

What purpose does compaction serve in a 64 bit virtual address space on Intel? The processor addresses and caches by cache line and the address space is huge enough to handle most allocations. Not to say it’s impossible in C/C++, but I’ve only ever seen fragmentation issues in old versions of Java and C# where the runtime repeatedly commits large swathes of contiguous memory. The key differentiator here is the VM’s insistence on contiguous allocations, whereas malloc has no such requirements.

kibwen 8y ago

It's a good question. As others have noted, jemalloc attempts to mitigate fragmentation, but you can't ever compact in a language where you can hand out pointers willy-nilly, so you would expect fragmentation to strictly increase as uptime approaches infinity. That said, Rust code doesn't tend to be especially allocation-heavy in the first place, and repeatedly allocating/freeing in a hot loop is already something that tends to be avoided as a core tenet of performance tuning, so allocator traffic may not be very heavy in the first place. I don't have any long-running Rust code myself, but I do know people who have had Rust servers that have been running for upwards of six months and they seem to be pleased at both how little memory it consumes and at how reliable it's been (you don't ever get tremendous uptime if your code isn't robust in the first place :P ).

steveklabnik 8y ago
Mostly, what I’ve heard about long-running processes is that, if they don’t have a leak somewhere, they tend to be pretty stable, so compaction isn’t a huge issue.
saosebastiao 8y ago
I'm definitely sympathetic to the argument that by avoiding allocation in the first place that you don't have to worry as much about memory profile. I allocate and destroy a bunch of arrays in my code (~100MB every minute), so it's not huge but definitely quite a few pages every time it happens. And so far I've got one process that's been running for 6 months. For the most part, whenever I get new data, I take a slice of an old array and append the new data to it to create a new array. It's fast enough, but more importantly it's just so much easier to do it that way and with a compacting GC I don't have to worry about anything. Of course I don't know how good jemalloc is at avoiding fragmentation, and I don't have the time to rewrite my code (maybe enough time to simulate, not sure). But my code creates a ton of fragment-y garbage, and I would imagine that with Rust I would end up not just translating my code, but changing semantics to mutate in place, just to avoid fragmentation. I guess maybe /r/rust would be the place to ask.