> All memory must be statically allocated at startup.

But why? If you do that you are just taking memory away from other processes. Is there any significant speed improvement over just dynamic allocation?

▲

matklad 3 hours ago | parent | next [-]

See https://github.com/tigerbeetle/tigerbeetle/blob/main/docs/TI... for motivation.

- Operational predictability --- latencies stay put, the risk of threshing is reduced (_other_ applications on the box can still misbehave, but you are probably using a dedicated box for a key database)

- Forcing function to avoid use-after-free. Zig doesn't have a borrow checker, so you need something else in its place. Static allocation is a large part of TigerBeetle's something else.

- Forcing function to ensure existence of application-level limits. This is tricky to explain, but static allocation is a _consequence_ of everything else being limited. And having everything limited helps ensure smooth operations when the load approaches deployment limit.

- Code simplification. Surprisingly, static allocation is just easier than dynamic. It has the same "anti-soup-of-pointers" property as Rust's borrow checker.

▲

pron 2 hours ago | parent [-]

> Forcing function to avoid use-after-free

Doesn't reusing memory effectively allow for use-after-free, only at the progam level (even with a borrow checker)?

	▲	muvlon 20 minutes ago \| parent \| next [-]
		Yes, kind of. In the same sense that Vec<T> in Rust with reused indexes allows it. Notice that this kind of use-after-free is a ton more benign though. This milder version upholds type-safety and what happens can be reasoned about in terms of the semantics of the source language. Classic use-after-free is simply UB in the source language and leaves you with machine semantics, usually allowing attackers to reach arbitrary code execution in one way or another.
	▲	matklad an hour ago \| parent \| prev [-]
		There's some reshuffling of bugs for sure, but, from my experience, there's also a very noticeable reduction! It seems there's no law of conservation of bugs. I would say the main effect here is that global allocator often leads to ad-hoc, "shotgun" resource management all other the place, and that's hard to get right in a manually memory managed language. Most Zig code that deals with allocators has resource management bugs (including TigerBeetle's own code at times! Shoutout to https://github.com/radarroark/xit as the only code base I've seen so far where finding such bug wasn't trivial). E.g., in OP, memory is leaked on allocation failures. But if you manage resources manually, you just can't do that, you are forced to centralize the codepaths that deal with resource acquisition and release, and that drastically reduces the amount of bug prone code. You _could_ apply the same philosophy to allocating code, but static allocation _forces_ you to do that. The secondary effect is that you tend to just more explicitly think about resources, and more proactively assert application-level invariants. A good example here would be compaction code, which juggles a bunch of blocks, and each block's lifetime is tracked both externally: * https://github.com/tigerbeetle/tigerbeetle/blob/0baa07d3bee7... and internally: * https://github.com/tigerbeetle/tigerbeetle/blob/0baa07d3bee7... with a bunch of assertions all other the place to triple check that each block is accounted for and is where it is expected to be https://github.com/tigerbeetle/tigerbeetle/blob/0baa07d3bee7... I see a weak connection with proofs here. When you are coding with static resources, you generally have to make informal "proofs" that you actually have the resource you are planning to use, and these proofs are materialized as a web of interlocking asserts, and the web works only when it is correct in whole. With global allocation, you can always materialize fresh resources out of thin air, so nothing forces you to do such web-of-proofs. To more explicitly set the context here: the fact that this works for TigerBeetle of course doesn't mean that this generalizes, _but_, given that we had a disproportionate amount of bugs in small amount of gpa-using code we have, makes me think that there's something more here than just TB's house style.

▲

AnimalMuppet 5 hours ago | parent | prev [-]

1. On modern OSes, you probably aren't "taking it away from other processes" until you actually use it. Statically allocated but untouched memory is probably just an entry in a page table somewhere.

2. Speed improvement? No. The improvement is in your ability to reason about memory usage, and about time usage. Dynamic allocations add a very much non-deterministic amount of time to whatever you're doing.

▲

pastage 42 minutes ago | parent | next [-]

Use mlock as long as it is allocated it is going to be rather deterministic, of course you might be running in a VM on an over commited host. I guess you can "prefault" in a busy loop instead of only on startup, waste memory and cpu!

▲

Ericson2314 5 hours ago | parent | prev | next [-]

If you use it and stop using it, the OS cannot reclaim the pages, because it doesn't know that you've stopped. At best, it can offload the memory to disk, but this waste disk space, and also time for pointless writes.

▲

norir 5 hours ago | parent [-]

This is true, whether it matters is context dependent. In an embedded program, this may be irrelevant since your program is the only thing running so there is no resource contention or need to swap. In multi-tenant, you could use arenas in an identical way as single static allocation and release the arena upon completion. I agree that allocating a huge amount of memory for a long running program on a multi-tenant os is a bad idea in general, but it could be ok if for example you are running a single application like a database on the server in which you are back to embedded programming only the embedding is a database on a beefy general purpose computer.

	▲	Ericson2314 4 hours ago \| parent [-]
		Yes it is context dependent, but the parent comment was acting as if it was just better. I wanted to correct that.

▲

jrmg 3 hours ago | parent | prev | next [-]

In response to (1) - you’re right, but that also implies that the added safety from static allocation when running on a modern OS is just an illusion: the OS may be unable to supply a fresh page from your ‘statically allocated’ memory when you actually write to it and it has to be backed by something real. The real stuff may have run out.

▲

kibwen 4 hours ago | parent | prev | next [-]

> On modern OSes, you probably aren't "taking it away from other processes" until you actually use it.

But if you're assuming that overcommit is what will save you from wasting memory in this way, then that sabotages the whole idea of using this scheme in order to avoid potential allocation errors.

▲

jeffreygoesto 4 hours ago | parent | prev [-]

Using this as well in embddded. The whole point is to commit and lock the pages after allocation, to not experience what you correctly describe. You want to have a single checkpoint after which you simply can stop worrying about oom.