WhenTestis inlined,we get something like this

Not only does this save the cost of calling Test,it saves compiling or running any of the expensive code that is now unreachable.

The Go compiler can automatically inline functions across files and even across packages. This includes code that calls inlinable functions from the standard library.

This does not imply that garbage collection makes Go slow,or that garbage collection is the ultimate arbiter of the speed of your program.

What it does mean is memory allocated on the heap comes at a cost. It is a debt that costs CPU time every time the GC runs until that memory is freed.

Unlike C,which forces you to choose if a value will be stored on the heap,viamalloc,or on the stack,by declaring it inside the scope of the function,Go implements an optimisation calledescape analysis.

If no references escape,the value may be safely stored on the stack.

Values stored on the stack do not need to be allocated or freed.

Lets look at some examples

Because the numbers slice is only referenced insideSum,the compiler will arrange to store the 100 integers for that slice on the stack,rather than the heap.

There is no need to garbage collectnumbers,it is automatically freed whenSumreturns.

Then we passcto theCenter()function which moves theCursorto the center of the screen.

Then finally we print the X and Y locations of thatCursor.

Even thoughcwas allocated with thenewfunction,it will not be stored on the heap,because no referencecescapes theCenterCursorfunction.

Because escape analysis is performed at compile time,not run time,stack allocation will always be faster than heap allocation,no matter how efficient your garbage collector is.

I will talk more about the stack in the remaining sections of this talk.

I want to step back for a moment and explore the history that leads us to goroutines.

In the beginning computers ran one process at a time. Then in the 60’s the idea of multiprocessing,or time sharing became popular.

In a time-sharing system the operating systems must constantly switch the attention of the CPU between these processes by recording the state of the current process,then restoring the state of another.

This is calledprocess switching.

First is the kernel needs to store the contents of all the CPU registers for that process,then restore the values for another process.

The kernel also needs to flush the CPU’s mappings from virtual memory to physical memory as these are only valid for the current process.

Finally there is the cost of the operating system context switch,and the overhead of the scheduler function to choose the next process to occupy the CPU.

Because a process switch can occur at any point in a process’ execution,the operating system needs to store the contents of all of these registers because it does not know which are currently in use.

As threads share address space,they are lighter than processes so are faster to create and faster to switch between.

Goroutines are cooperatively scheduled,rather than relying on the kernel to manage their time sharing.

The switch between goroutines only happens at well defined points,when an explicit call is made to the Go runtime scheduler.

The compiler knows the registers which are in use and saves them automatically.

Places where Goroutines may yield to others are:

• Channel send and receive operations,if those operations would block.
• The Go statement,although there is no guarantee that new goroutine will be scheduled immediately.
• Blocking syscalls like file and network operations.
• After being stopped for a garbage collection cycle.

The thread,depicted by the arrow,starts on the left in theReadFilefunction. It encountersos.Open,which blocks the thread while waiting for the file operation to complete,so the scheduler switches the thread to the goroutine on the right hand side.

Execution continues until the read from thecchan blocks,and by this time theos.Opencall has completed so the scheduler switches the thread back the left hand side and continues to thefile.Readfunction,which again blocks on file IO.

The scheduler switches the thread back to the right hand side for another channel operation,which has unblocked during the time the left hand side was running,but it blocks again on the channel send.

Finally the thread switches back to the left hand side as theReadoperation has completed and data is available.

Any time your code results in a call to the operating system,it will go through this function.

The call toentersyscallinforms the runtime that this thread is about to block.

This allows the runtime to spin up a new thread which will service other goroutines while this current thread blocked.

This results in relatively few operating system threads per Go process,with the Go runtime taking care of assigning a runnable Goroutine to a free operating system thread.

There is another side to the goroutine story,and that is stack management,which leads me to my final topic.

Traditionally inside the address space of a process,the heap is at the bottom of memory,just above the program (text) and grows upwards.

The stack is located at the top of the virtual address space,and grows downwards.

This is called a guard page,and effectively limits the stack size of a process,usually in the order of several megabytes.

Because it is hard to predict the stack requirements of a particular thread,a large amount of memory is reserved for each thread’s stack along with a guard page.

The hope is that this is more than will ever be needed and the guard page will never be hit.

The downside is that as the number of threads in your program increases,the amount of available address space is reduced.

Instead of using guard pages,the Go compiler inserts a check as part of every function call to check if there is sufficient stack for the function to run. If there is not,the runtime can allocate more stack space.

Because of this check,a goroutines initial stack can be made much smaller,which in turn permits Go programmers to treat goroutines as cheap resources.