Runtime Machinery

G is a goroutine, M is an OS thread, and P is a scheduling context an M must hold to run Go code. GOMAXPROCS sets how many Ps exist, so it caps how much Go code runs at once.

Nothing blocks at the operating-system level. Go's runtime parks the goroutine, marking it waiting and detaching it from the thread, then runs another runnable goroutine on that same thread. The thread keeps doing useful work.

No. When a goroutine enters a system call that blocks, the Go runtime detaches its P (the scheduling context) from that OS thread, and another thread picks the P up and keeps running the remaining goroutines.

Nothing at the OS level blocks. The Go runtime parks that goroutine and records its wake time in a runtime timer heap, freeing the thread for other goroutines; when the deadline passes the goroutine becomes runnable again.

GOMAXPROCS sets the number of Ps, capping how many goroutines execute Go code at the same time. It does not cap how many goroutines you can create, and it is not a ceiling on the OS threads the runtime may create.

Yes. Go has no dangling pointers: at compile time escape analysis sees that the address outlives the function's frame, so the compiler allocates that variable on the heap instead of the stack. The garbage collector frees it later.

make([]byte, 0, 4096) reserves a 4096-byte array but starts with length 0, so appends fill it without reallocating. make([]byte, 4096) sets the length to 4096, so the slice already holds 4096 zero bytes and append adds data after them.

Each P owns an mcache holding one span per size class, so the usual allocation is a lock-free pop. An exhausted span is refilled from that class's shared mcentral, which takes fresh spans from the global mheap.

Go's heap allocator rounds every small allocation up to one of about 68 fixed size classes, and 24 is the first class that fits 17 bytes. Fixed sizes let one span hold identical objects with no per-object header.

Each Go function starts by checking whether enough stack space is left. If not, it calls into the runtime, which allocates a new stack of double the size, copies the old stack into it, and lets the function continue.

runtime.SetFinalizer registers a function the Go runtime may call some time after an object becomes unreachable. The runtime guarantees almost nothing: it runs on a later garbage-collection cycle, or not at all, and never at program exit.

GOGC is a growth percentage, not a size. At the default GOGC=100 the runtime sets the next heap goal at roughly double the live heap the last cycle measured: 200 MB live gives a goal near 400 MB.

Go's garbage collector is a concurrent tri-colour mark-and-sweep collector that is neither generational nor moving. A heap object keeps the same address for its whole life, and there are no young or old generations to promote between.

Track the live-heap figure in gctrace across many cycles, not one sample. Flat while resident memory stays high means the runtime is holding freed spans it has not given back. A real leak makes that figure climb steadily.

A mark assist is garbage-collection marking work the Go runtime makes an allocating goroutine do itself. During a collection cycle, allocating memory charges your own goroutine some scanning, so the busiest allocators pay for the collector's backlog.

Go's runtime starts every map iteration at a randomly chosen position, so map order is undefined and changes from loop to loop. For stable output, copy the keys into a slice, sort it, and index the map in that order.

append returns a new slice value and never updates the slice you passed in. If the backing array has no spare room, append allocates a bigger array, so only the returned value is guaranteed to see the appended element.

A Go slice value is three words: a pointer to the first element it covers in a backing array, a length, and a capacity. The elements live in that array, not inside the slice value.

A Go string value is a two-word header: a pointer to an array of bytes plus a length. Assigning or passing a string copies only that header (16 bytes on a 64-bit platform), never the text it points at.

A slice is passed by value, so the callee gets its own copy of the three-word header. Writes through the shared pointer reach the caller's elements; assigning a new length or capacity only changes the callee's copy.

Neither form is faster. Both run the same dynamic-type check and differ only in failure: the comma-ok form yields T's zero value and false, while the single-value form panics with a message naming the actual and the requested type.

The interface's type word is set to the Sink and *fileSink pairing while its data word is nil, so the value is not equal to nil. The guard passes, the call dispatches, and the method dereferences a nil receiver.

A pair of words: the dynamic type *os.File, plus a data word pointing at the file. The variable is not a copy of the file, and it carries the concrete type along, which is why %T prints *os.File.

Go links statically and ships the whole runtime — collector, goroutine scheduler, allocator — plus per-type metadata, the function and line tables behind stack traces, and debug information. That fixed baseline dwarfs a tiny program's own code.

A concrete target is one comparison: the value's dynamic type against that type's descriptor, whose address is fixed at build time. An interface target makes the runtime match the whole method set, then memoise the answer.

Go's defer is scoped to the function call, not to the block or the loop iteration. Every trip through the loop registers one more deferred Close against the same frame, and none of them run until the enclosing function returns.

A panic stops normal execution and unwinds the goroutine's stack, running every deferred call on the way up. Unrecovered, the runtime prints the panic value plus a stack trace to standard error and exits the whole process with status 2.

Each Go traceback frame is two lines: the qualified function name with hex words for its arguments, then an indented source file and line plus a +0x offset into the function. Frames print innermost first, so the top one panicked.

An open-coded defer is one the Go compiler inlines: it keeps the call in stack slots, sets a bit in a bitmask, and calls it at each return. Defers in a loop, or more than eight per function, fall back to runtime records.

It compiles to three steps: assign 5 into the named result's slot, run the frame's deferred calls, then return to the caller. Because the defers run in between, a deferred closure writing to that named result changes what the caller receives.

The Go runtime starts first: it sets up the heap, the goroutine scheduler and the garbage collector, then creates the main goroutine. That goroutine initialises every imported package - package-level variables, then init functions - and only then calls main.main.

os.Exit ends the process immediately. Deferred functions never run, so anything a defer would have flushed or closed is lost: bytes still sitting in a bufio.Writer never reach the file or the terminal.

Go's scheduler found nothing left to run: every goroutine is parked on a channel operation, a lock or a similar wait, so none can ever wake another. The runtime aborts the whole program immediately.

Because it is not a panic. A fatal runtime error skips stack unwinding entirely: the runtime freezes the other goroutines, prints the banner and every goroutine's stack, and exits. Deferred calls and recover never enter the picture.

All package initialisation runs sequentially on the main goroutine, before main.main is called. If one init function blocks - on a channel, a lock or a network call - startup stops there: the process stays alive but main never runs.