Static Allocation, Constant Work

Static Allocation, Constant Work(matklad.github.io)

104 points by surprisetalk 1 day ago | 20 comments

mrkeen 5 hours ago |

> TigerStyle: All memory must be statically allocated at startup. No memory may be dynamically allocated (or freed and reallocated) after initialization. This avoids unpredictable behavior that can significantly affect performance, and avoids use-after-free.

Maybe maintaining an array of NULL-orders satisfies the letter of the "no dynamic allocation" law, but I'm not convinced it satisfies the spirit.

Haven't you just written a buffer of NULL-orders, which you proceed to loan out to callers (i.e. "allocate" and "reallocate"?).

Someone else's battle-hardened allocator might be slow or buggy, so you write your own as part of the business logic implementation?

nickmonad 3 hours ago | |

TigerStyle is strictly concerned about dynamic allocation from the perspective of the OS.

Once you have that pool of "objects" that can be recycled throughout the lifetime of the program, you have a guarantee that actual allocation can only be interpreted in a specific way, i.e. all objects have the same size, alignment, etc so you don't have nearly the same level of concern or detail of implementation as an actual allocator in the common understanding of the word. A simple free-list gets you pretty far.

obviouslynotme 1 hour ago | |

>Someone else's battle-hardened allocator might be slow or buggy, so you write your own as part of the business logic implementation?

In infrastructure where speed and reliability are highly valued? Absolutely. The gains obtained from proper memory layout and specialized use are massive. As long as you have the reason to do it, it's an easy win. I believe that the Zig standard library has different specialized allocators, so you don't even have to write your own buggy implementation.

nwjsmith 4 hours ago | |

It’s (mostly) not about performance, it’s about minimizing failure. Static memory allocation makes you OOM-proof.

irq-1 2 hours ago | | |

> Static memory allocation makes you OOM-proof.

It ensures you don't cause an OOM error. Your app can still be killed by OOM.

skavi 3 hours ago | | |

seems not as great for consumer software in uncontrolled environments. static allocation means the application hordes memory that the OS should probably be able to provide to other processes. constant work probably leads to higher average power usage.

ferguess_k 1 hour ago |

I'm an amateur of C and knows nothing about Zig, so I'm not sure if this is equivalent to a C Union. But shouldn't we leave these kinds of problems to the programmers, not the language designers? Or did I miss anything?

> We have a tagged union, which can hold either A or B. We initialize the union as A, take a pointer to its internals, overwrite the original with B, and then use the pointer. The pointer is still typed as A, but the bytes it points to now belong to B: a type confusion.

markus0 6 hours ago |

I want to work more with systems that always abide by such strict constraints and style / design guides, but at the same time I feel like the reality of building software at scale is teams ending up working in subsystems that don’t consider the holistic operating model of the program. So even with best practices locally, the system as a whole ends up fragmented and inefficient, and strict global constraints therefore feel limiting.

pjmlp 6 hours ago |

Interesting how everyone keeps rediscovering 8 and 16 bit home computer programming techniques, after all these years, mostly I guess caused by the scripting languages for everything during the last two decades.

donkeybin 26 minutes ago | |

You’ve said enough that I think we can safely ignore your tech advice.

How you got that karma is a mystery - not from your technical knowledge.

A quick peruse through your comments has been quite the laugh - a nervous laugh nonetheless.

I can’t believe you are our future. :/

SPascareli13 6 hours ago |

I never fully understood how to work with this "reserved" values being valid instead of errors when you can't allocate more memory, in either case you still need to check if you have a real entity or a reserved/error, right? Does it really make things simpler?

AlotOfReading 6 hours ago | |

It helps avoid the happy path effect. You're always handling something and there's no hidden control flow from the program runtime creeping in because of the cases you missed.

Tcepsa 6 hours ago | |

In the reserved case you do still need to check if you have a reserved entity, but you can put it (along with the other allowed "pseudotypes") in a switch/case block and have it just break back out immediately (the no-op mentioned in the article) rather than having to use a separate if/else to check for Null, or clutter things up with a try/catch wrapper.

Does that address what you're asking about?

SPascareli13 6 hours ago | | |

But that assumes I have some switch case somewhere right? If I passed an array of "orders" to a downstream function, it knows that what it has is orders, not something else, so it doesn't need to check for anything, and in the case I checked for errors upstream (when I try to allocate a new order) all downstream functions know that no invalid order can be passed, in which case you only have one check at creation time.

That's why I haven't fully understood yet how working like this is simpler.

sjducb 6 hours ago | | |

Why is a try/catch wrapper clutter but a switch case is not?

theokrueger 7 hours ago |

static allocation is de-facto standard in embedded for obvious reasons, and works really well there. in operating systems with more complex memory models designed entirely around dynamic workloads, im not sure asking devs to adopt another slightly complicated design pattern that imposes new hard caps is any less of a cognitive load than before.

i can't bash the functionality and correctness aspect of static allocation, but it is akin to the humble linked list in the sense that you should already know going into the problem that you need it.

AlotOfReading 6 hours ago | |

Someone recently made the point to me that a lot of dynamic situations can be rewritten as locally static allocations with proper continuations. The idea being that you re-enter the continuation with more memory when you've exhausted your existing pools. The problems are obvious, but it's a neat middle ground.

senderista 6 hours ago | | |

The simplest example being a stack buffer that expands to a heap allocation when required. There is an API pattern to facilitate this: when the size of the provided "out" buffer is insufficient to hold the result, return an appropriate error code and populate an out parameter with the required size. So you try once with the stack buffer, and if that fails, retry after allocating a heap buffer of precisely the required size. We used this pattern everywhere in Windows dev.