4 ms·

I wrote a commercial memory allocator (long long gone) for pre MacOS 10 and tested it by writing a ton of memory bashing applications based on every perverse pa

I wrote a commercial memory allocator (long long gone) for pre MacOS 10 and tested it by writing a ton of memory bashing applications based on every perverse pattern I could think of in order to ensure it was fast, failure free and limited fragmentation. Of course from that era I didn't need to support multiple threads so that made it somewhat easier, but in building it (and studying others at the time) it was obvious that this is far from a solved science, and there were terrible design decisions in many common allocators at the time that made little sense. It clear that some of these decisions still hang around today and that switching to a better allocator really can make a huge difference, especially given everything is multiple threads/cores today. But a lot of programmers never even look at memory usage or investigate alternatives. Even the JVM has a boatload of options on allocators for different usages; yet most Java programmers I know just go with the defaults. Computers may be ridiculously fast and have enormous memory today and maybe you can live with the default; but it doesn't hurt to look, and might even save you money (pay less to AWS!) by reducing your need to allocate more or bigger servers.

swiftcoder 6y ago
> Computers may be ridiculously fast and have enormous memory today and maybe you can live with the default Often these hardware improvements exacerbate problems with memory management. For years the runtime of the default JVM garbage collector would blow up past 48 GB of allocations. Which was probably fine for 99% of software out there, but the day your honking great server blew past that... was a bad day all round. It pays to know your allocators and garbage collectors inside and out for modern cloud scale computing.
- nicoburns 6y ago
  I'm not quite sure why, but Java/JVM seems to be uniquely bad with regards to memory usage. Nothing else seems to use quite so much memory. It's expected that C/C++/Rust would be better, but similar languages like C# also seems much better. Even Python/Ruby/JavaScript don't seem as bad.
- AtlasBarfed 6y ago
  Yeah, it's a huge probelm with Cassandra. The 4.0 version of cassandra is finally doing the smart thing and spinning up separate threads dedicated to sets/shards of hash ranges held by a node. I'm not sure if they'll run different JVMs per thread as well to do further sharding of the GC generations as well or if they can effectively do that from one JVM, but that would make sense
Rendello 6y ago
It's interesting that I saw this post minutes after watching the talk "What's a Memory Allocator Anyway?" by Benjamin Feng. It's ostensibly about Zig's allocation schemes, but it's more of a general overview of the varied (single-thread) allocation strategies in use today. It made me really want to try out arena allocators It's a quick watch at 1.5x speed, the last third is an interview. 1. https://youtu.be/vHWiDx_l4V0 https://youtu.be/vHWiDx_l4V0
AtlasBarfed 6y ago
Is heap management that far from the algorithmic headaches of Garbage Collection? Compiled languages typically are "arena allocators" by default and probably don't hit these similar heap management/paring/centralizing/compaction problems until they do a ton of dynamic datastructure allocations and manipulations. ... and they get to punt to the OS too. I'd certainly believe this isn't a "solved" problem.

swiftcoder 6y ago

> Computers may be ridiculously fast and have enormous memory today and maybe you can live with the default Often these hardware improvements exacerbate problems with memory management. For years the runtime of the default JVM garbage collector would blow up past 48 GB of allocations. Which was probably fine for 99% of software out there, but the day your honking great server blew past that... was a bad day all round. It pays to know your allocators and garbage collectors inside and out for modern cloud scale computing.

nicoburns 6y ago
I'm not quite sure why, but Java/JVM seems to be uniquely bad with regards to memory usage. Nothing else seems to use quite so much memory. It's expected that C/C++/Rust would be better, but similar languages like C# also seems much better. Even Python/Ruby/JavaScript don't seem as bad.
AtlasBarfed 6y ago
Yeah, it's a huge probelm with Cassandra. The 4.0 version of cassandra is finally doing the smart thing and spinning up separate threads dedicated to sets/shards of hash ranges held by a node. I'm not sure if they'll run different JVMs per thread as well to do further sharding of the GC generations as well or if they can effectively do that from one JVM, but that would make sense

Rendello 6y ago

It's interesting that I saw this post minutes after watching the talk "What's a Memory Allocator Anyway?" by Benjamin Feng. It's ostensibly about Zig's allocation schemes, but it's more of a general overview of the varied (single-thread) allocation strategies in use today. It made me really want to try out arena allocators It's a quick watch at 1.5x speed, the last third is an interview. 1. https://youtu.be/vHWiDx_l4V0 https://youtu.be/vHWiDx_l4V0

AtlasBarfed 6y ago

Is heap management that far from the algorithmic headaches of Garbage Collection? Compiled languages typically are "arena allocators" by default and probably don't hit these similar heap management/paring/centralizing/compaction problems until they do a ton of dynamic datastructure allocations and manipulations. ... and they get to punt to the OS too. I'd certainly believe this isn't a "solved" problem.