On Wed, Jan 25, 2017 at 12:40 AM, josvazg <josv...@gmail.com> wrote: > > Here are my takeaways (with a few questions): > > There is not a clearly defined GolangRT subset (at least for now), it is a > moving target requiring very low level knowledge on the compiler inner > workings. > For the runtime, implicit memory allocations are flagged by the compiler > with a secret option. > > Why not make this available to normal users? won't it be useful on some use > cases?
Because then we would have to define it formally, as you suggested. Right now the option just means "whatever we need to help ensure that the Go runtime is correct." > When memory is actually needed by the runtime, either use the stack if > possible or use 'persistentalloc' but no free: > > Can't that mean that the runtime may leak memory if golang userland > repeatedly requests work so that the runtime calls persistentalloc > repeatedly? The runtime doesn't do that. It only uses persistentalloc for things that wil remain live for the rest of the program. > Can in go runtime a stack allocated memory be used by callees of the > function that allocated that memory on its frame? Or is it restricted to > only live in its own function? Memory allocated on the stack in function F can not be used by callees of F. After F returns, the memory is gone. > The runtime must be using it's own memory space, managed separately to the > one it provides to Golang userland. I infer this as userland memory can be > requested, freed (by the GC) and even given back to the OS. Only for the special case of persistentalloc. > The runtime seems to be: > > A library when userland requests a service from it, so it runs in the same > thread as the user code? Yes, although speaking of "threads" can be misleading when talking about Go. > A set of active tasks, like the GC, that are basically single threaded. Yes, although the GC is not single threaded. > When a go program is single threaded as well, does the runtime share the > thread or does it live on a separate OS thread anyway? It's misleading to speak of "threads" in a Go program. A Go program is never single-threaded. But if GOMAXPROCS == 1, then in general only one thread will be executing at a time. The runtime code doesn't execute in separate threads, but it does execute in separate goroutines. > The stack size for the runtime is static. For some parts of the runtime, yes, specifically the parts that handle stack copying. > GolangRT subset language not only is fuzzy and changing, it is also very > limited to me generally useful for anything else. Yes. Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
