Kyren223/resources
1
1
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Replace rambling explanation with my new blog post

Browse Source
This commit is contained in:
Kyren223
2025-09-25 23:33:02 +03:00
parent 5b07c6c347
commit bb25494895
1 changed files with 4 additions and 31 deletions
Download Patch File Download Diff File Expand all files Collapse all files

35
README.md
View File

@@ -76,6 +76,10 @@ I'd recommend either skipping it, or rewatching it multiple times, until you ful
First, realize you _do not_ know how to _actually_ manager memory, so throw away all the misconceptions u have been taught.
[How memory works by Kyren223 (me)](https://kyren.codes/blogs/how-computer-memory-actually-works/) - Goes over how your program interacts
with memory nowadays, knowing about virtual memory and virtual address space would be crucial to
understand the rest of the resources here.
[Enter the Arena by Ryan Fleury](https://www.youtube.com/watch?v=TZ5a3gCCZYo) teaches about arenas, the "magical" allocator (actually it's dead simple and not magical).
Goes over arenas in general, permanent areans, transient (temporary) arenas, and scratch arenas.
@@ -96,37 +100,6 @@ For arena implementations, see [Krypton](https://git.kyren.codes/kyren223/krypto
about individual objects/allocations is REALLY hard, and that grouping allocations makes managing memory REALLY easy.
And what's a better way of grouping allocations then arenas (one arena per group of objects/lifetimes).
Also a bit of an explanation from me, because all these talks do mention this, but gloss over it:
Computers have physical and virtual memory.
If you are running on a 64-bit machine, it means pointers are 64-bit, but u don't actually need 2^64 bytes.
Usually, only the 48 bottom bits are used, which total to 256TB of RAM[^2] (note, only the top 8 bits are unused, and they are reserved[^3])
This gives you 256TB of "virtual address space".
And the CPU has special tables that translate virtual memory addresses into physical addresses "automatically",
so you don't have to worry about it.
Operating systems work with "pages" (usually 4kb), and allow you to either "commit" or "reserve" pages.
Pages are the smallest unit of memory you can ask from the operating system.
Reserving pages tells the OS to mark them as "used", so if you ask it for more memory, it would not return a "reserved" page.
Committing pages actually asks the OS "hey, give me physical memory to back this page".
Physical memory is (almost) always segmented, but from your program's point of view, virtual address are continuous,
even if the backing physical memory of pages is scattered.
Knowing this, arenas are usually implemented by reserving a large chunk of virtual space,
but only committing it as needed.
This allows for more efficiency in growing arenas, compared to using malloc (which is a 6k lines wrapper around committing/reserving OS virtual memory).
If you have used C++ (and maybe Rust), you'd know that you can't keep pointers from a list after
you append to the list, why?
Because the list (vector) might need to grow, which means, allocating a new chunk of memory, copying
all the elements, freeing the old chunk, this is known as "unstable pointers" (bcz u can't rely on them).
Now, what if instead, we reserved a huge chunk, say 64GB of _virtual_ address space, now when the list needs to grow,
we don't need to re-allocate, and copy, which is VERY expensive, we only need to tell the OS to commit more pages.
Obviously in a real application, unless you know the list is REALLY large, you are probably fine reserving a smaller amount, like 64MB.
### Game Development
TODO: this took me very long to make, will add this later (remind me if I forgot!)