Zig in Depth: Memory Management

NOTE: This series only covers Zig 0.11.0! Help me create more content like this!
www.paypal.com/donate/?hosted...
Get yourself a cup of coffee, this is going to be a long video. :^) Memory management in low-level systems programming is a fundamental skill to master. In Zig, it's at the core of the language's philosophy of being explicit, not hiding control flow, and offering maximum power and flexibility to the programmer. In this episode we cover the foundational knowledge you'll need to start mastering manual memory management in Zig. The stack, heap, and static memory sections are explained, as well as the concept of allocation and freeing heap memory.
The code: codeberg.org/dude_the_builder...
Relevant Link: ziglang.org/documentation/0.1...

[@bogdankizka6580]

You are very good at making things clear in your Zig series. Thank you!

[@jamesbyrd405]

You’re a legend. Thanks!

[@olivehillstudios]

Thanks so much for this series! You are a great teacher, truly very skilled at explaining this stuff.

[@thilina91]

I learned so much from this video. Thank you! Absolutely loving the video series!

[@jefmyers502]

i want to smash the like button over and over... thank you for making these videos!

[@thomasskarshaug7374]

Really great video, thanks for making this!

[@thilankaliyanaarachchi984]

Super helpful video! Would love to see more Zig content from you.

[@dudethebuilder]

I'm glad this content is helpful and thanks for the support! Here's a link to the full playlist: kzbin.info/aero/PLtB7CL7EG7pCw7Xy1SQC53Gl8pI7aDg9t&si=lTju4b9OpXRRq_hw

[@alex_d_lee]

These vids are amazing thanks bro

[@stef2528]

Great explanation! Thank you!

[@nlight8769]

35:50 "But we'll be talking a lot more about memory management in Zig in future videos, don't worry about that" Oh Gosh 😅 Great video, I gotta practice, practice and practice again now... Thank you, that is great stuff

[@kyp0717]

Thank you! Thank you! Thank you!

[@user-dz6il2bx5p70]

That's probably one of the best videos about memory management in Zig (and not only). A dumb question arises from me, what happens with the allocator, do you need to destroy it as well

[@dudethebuilder]

Good question; and it depends on the allocator. Allocators are just structs themselves that implement the std.mem.Allocator interface, and depending on how they work they may need resources to be cleaned-up on exit. In those cases, you'll see a `deinit` method that you can call with `defer` to make it easy to do that clean-up process.

[@RobertVoogdgeert]

What a wonderful series! Watched all of them and they are so helpful. Thank you so much. I have one question about the std.mem.copy function. In the Standard Library Documentation it is no longer mentioned. Instead the @memcpy built-in is the default. At std.mem.copy is says: Deprecated: use if the arguments do not overlap, or if they do. So my question is it still save in the near future to use std.mem.copy?

[@dudethebuilder]

The norm in Zig's development so far has been if you see such a comment about something being deprecated, you should find an alternative (usually suggested in the comment too) because it will be removed from the language. In the case of std.mem.copy, you can use the @memcpy builtin or std.mem.copyForwards depending on whether the arguments are overlapping areas of memory. In my experience, the @memcpy builtin pretty much covers most of the situations where you needed std.mem.copy.

[@shoulderstack5527]

Hey, thanks for these great series of videos. One question, is that correct at 8:22 where you say that var 'result' is copied when function 'locals' returns? Is it not true that 'result' memory is actually in the stack frame of the parent function all along?

[@dudethebuilder]

Strictly in the realm of semantics and scopes, the memory for the return value of a function is indeed within the caller's stack frame. But at the same time, all variables defined within a function are local to that function and allocated in that function's stack frame. So here, "result" is a local variable allocated in the stack frame memory of the function "locals", and when the function returns, that memory is copied to the return memory location of the caller. Now, in reality, the compiler will optimize most of this copying away and the final machine code behaves as you say, with the "result" being placed directly in the function result location without any copying.

[@shoulderstack5527]

So it's like the coder's perspective and then the compiler's perspective. This is great stuff, thanks. @@dudethebuilder

[@jizhang9394]

👍

[@pietraderdetective8953]

do you have any guesstimate on when Zig will reach stable version 1.0 ? I would love to use Zig, but at the moment there are breaking changes..hence better to wait until it's stable.

[@dudethebuilder]

When you look at Zig from the perspective of other new programming languages, it seems it's moving too slowly; taking too long to get to 1.0. But after observing the evolution of the language for some time now I have realized that this slow pace has allowed the language to make some ver wise design decisions, and test others that haven't proven to work out and have been removed. So I can't offer an estimate, it will probably be counted in years, but the final result will be a very robust and stable 1.0. For now, if you are dealing with critical software, Zig isn't the ideal option, unless you're willing to rapidly adapt with the breaking changes.

[@pietraderdetective8953]

@@dudethebuilder yeah I actually like it on the short time I tried it for several days...but then I got stuck for like a couple of hours only to find out some of the built-in functions were deprecated. I will definitely come back to it once it's stable and I do expect it will take around 2-3 years to reach version 1.0

[@muhammadshakeelansari6719]

Is the copy() function replaced with copyForwards() and copyBackwards() in Zig 0.12.0? Used in the code at line number 45.

[@dudethebuilder]

If the destination and source may overlap you should use those function in std.mem, but if there is no overlap you should use the @memcpy builtin.

[@muhammadshakeelansari6719]

​@@dudethebuilder Thanks a million!

[@david2am]

Hi, just a quick question, the global const section and the global data section... do they both correspond to the static memory right?

[@dudethebuilder]

Yes. At a more technical level, there are some more details involved, like for example when global variables have an initial value versus when they don't (data vs bss) but for the purpose of these demos, the higher level blocks view works well.

[@david2am]

@@dudethebuilder thanks I appreciate it!

[@flyLeonardofly]

My understanding is that stack, heap and static memory all live in RAM. Is this correct? If yes why is the distinction between static, heap and stack so important? Ofc knowing that all stack frame data goes away is crucial, but there is a lot of performance talk that I would like to understand and it is all about stack vs heap...

[@dudethebuilder]

Excellent observation. You are right, all program memory (aside from little bits in CPU caches and registers) resides in RAM, so the access speed is the same. The big difference in terms of performance is actually due to reduced computation. Static and stack memory contents are all fixed-size objects whose sizes are known at compile time so when the program starts all of this space can be allocated at once in a single system call to the OS. Dynamic allocations on the heap while the program runs, on the other hand, have to be allocated and freed individually, making syscalls each time, which are costly. That's basically the main difference in performance.

[@flyLeonardofly]

@@dudethebuilder thank you very much for this explanation!

[@ant1fact]

I always wonder if the background noises are artificial or if you are actually sitting outside :D

[@dudethebuilder]

LOL. Believe me, if I were sitting outside you would think I was coding in the middle of the jungle.

[@ant1fact]

@@dudethebuilder Lol where are you located?