Understanding Allocations: the Stack and the Heap - GopherCon SG 2019

Speaker: Jacob Walker, Ardan Labs (@jcbwlkr)
Like C, Go uses both stack and heap memory. How can a Gopher know which is being used? Can you influence this decision? What effect does it have on your program? Are there any tools to help? This talk answers those questions and more.
About the speaker
Jacob is a software developer, community organizer, and has really nice hair. Like ridiculously nice hair.
He started his career creating web applications in PHP, Ruby, and Node.js. When he discovered Go he dove in deep and hasn’t regretted it for a minute. He is now a Community Engineer with Ardan Labs where he is focused on helping members of the Go community.
Event Page: 2019.gophercon.sg

[@HSharpknifeedge]

So far, this is the best explanation of Escape Analysis, comparing with many others, which are right now on the right side of the screen, suggesting by KZbin. Awesome, thanks again!

[@jaredcastro8862]

I also agree. Clean and short

[@ugur_dincer]

Clear and smooth, also io.Reader part was nice

[@nyashachiroro2531]

It was super nice. Literally an aha moment for me. This was a great talk.

[@TehKarmalizer]

It made me think of similar functions in other garbage collected languages differently as well.

[@Pherecydes]

I hadn't understood why the io.Reader interface works the way it does... now I get it, thank you! Excellent talk.

[@wentaoqiu4072]

Simply amazing, points are clear and explained throughly, thanks so much.

[@anaray567]

This clear why io.Reader is designed the way it is ! Very clear and precise presentation ! Thanks

[@thepolyglotprogrammer]

Really good example about the io.Reader.

[@Wielorybkek]

That was super interesting, I've learnt a new thing!

[@nicksypteras8594]

That io.Reader example at the end was great!

[@ideaparkcc]

It can be concluded that: system api should not be responsible for resources management (most of times it refers to memory), but only for logical evaluation.

[@kamilziemian995]

21:20 Great ending point to great presentation.

[@jub0bs]

Excellent talk!

[@alex6161]

The best explanation, thank you Jacob !

[@luqmansen]

Great explanation!

[@KurtisRader]

The question at the end of the talk is interesting. I would have provided a slightly different answer. The primary way to address performance concerns is by picking the appropriate data structures and algorithms. It is almost always a mistake to focus on minutiae; i.e., usually insignificant implementation details.

[@baxiry.]

usefull

[@АлександрКостюченко-у4х]

He is really good. Thank you!

[@rogeriof2315]

Really nice explanation!!!

[@CLE2022]

This is really good

[@vamsikrishnasiddu3525]

Amazing explanation

[@speedTurtle]

Cogent. I learned something here.

[@mzcustom2]

I think the point he made at 14:00 could be somewhat misleading as he's emphasizing "moved to the heap right at compile time". The escaped variables still have to be dynamically allocated in heap, so it's complied to call runtime.newobject which calls mallocgc, therefore there's no cost benefit at runtime. Also, I believe this speaker isn't experienced in C programming, not that I'm faulting it, judging by the fact he initially didn't understand why the read function of io.Reader uses a byte slice as its argument instead of an int. That's exactly how read in C works where the caller sends a buf pointer (along with the buf size or less) and gets the number of bytes filled in as the return value, just like all the other functions do unless the argument is a small struct that fits in the registers or a primitive type. From what's known, Golang is a brainchild smart men from Bell Lab who hated C++, so it quite closely follows Unix/C programming style.

[@edb75001]

Very informative... much appreciated.

[@xiaodonghuan2285]

Thanks for your reply. nice post!!!

[@GertCuykens]

Can I assume that most return err values in common golang programs end on the heap? Or does err get special treatment?

[@foolishway4257]

Good question.

[@marianzagoruiko]

I don't think it does. Allocation only happens if you return a pointer to the variable. In case of error, the value is being returned and not a pointer.

[@swibay]

​@@marianzagoruiko You're right!

[@a_maxed_out_handle_of_30_chars]

wow, I came looking for copper and found gold

[@kevingeorge3983]

awesome

[@johnedissonrodriguezcucanc9131]

Amazing explanation, I just have any doubt, what is the difference between "&x scapes to heap" and "moved to heap". Thks

[@shubhamdhapola5447]

It's just the matter of how much of the program behaviour the compiler is able to acknowledge. At compile time, the value a variable holds "escapes" to (allocated on) the heap, if the compiler is confident and almost-omniscient of the program's semantics and control flow in the vicinity of variable declaration and usage (like Go, unlike Python). Else if compiler only has partial information, it will allocate an empty memory slot for the variable ahead-of-time and runtime behaviour will unveil that it needs to be "moved" to the heap.

[@slabchan7310]

Thanks for sharing

[@Mimookrokodill]

Awesome

[@kanybekmomukeev4116]

Best of best

[@AnonAristotel]

Awesome.

[@EdwardWork-m5t]

Thank you beer belly Jesus

[@DagangWei]

17:30 wondering why in the right hand case, it is not `read(&b)` and `func read(b *[]byte)`? in other words, why it doesn't need pointer? (I am new to Golang)

[@JacobWalker0814]

The structure of a slice contains a pointer to a backing array of elements. You almost never take the address of the slice itself since it behaves like a pointer already.

[@DineshGowda24]

Slice will already have a pointer to an array. When you pass a slice to the function, even though the slice will be copied only the underlying address of array will be copied. So any changes on slice will affect the underlying array. So need to pass potiner to slice. Also a slice would look like struct slice{ ptr *[cap]Type, cap int, len int}

[@TehKarmalizer]

@@DineshGowda24 it really depends on what you are doing with the slice. If there may be side effects that reallocate the underlying array (and therefore the slice), that reallocation will be local inside the function, and the original slice and array will be unaware of the side effects. Maybe that is desirable, but maybe it is not.

[@marianbuciu7853]

can someone explain 17:55?

[@androth1502]

so why can't we just put stuff on the bss segment?

[@elio8119]

Because Go was created to be simple and not support this kind of intrinsics.

[@gngn2973]

If i understand correctly, for "correctness", you want to try your best to stay off of the heap whenever possible? Great video really cleared some things up for me, being a fairly new programmer.

[@TehKarmalizer]

No, for correctness, you want the program to perform the intended behavior. And you want it to keep doing so when anyone needs to change the code.

[@gngn2973]

@@TehKarmalizer yea I've come a long way since that comment lol. Thank you for the response tho =)

[@mridulrathod3681]

superlike

[@yapayzeka]

who put the like at 1:05 :D

[@user-ge8fn4jr5q]

wtf is go anyway...

[@Jonasmelonas]

ok boomer

[@TheMrKeksLp]

ok zoomer

[@Aditya-ne4lk]

fumt