On Wednesday, January 25, 2017 at 5:16:07 AM UTC+8, Ian Lance Taylor wrote: > > On Tue, Jan 24, 2017 at 12:46 PM, josvazg <jos...@gmail.com <javascript:>> > wrote: > > > > Golang runtime has been fully translated to Go for a while now. I know I > > could just read the source code directly but... > > > > Is there any known or recommended documentation (talk, slides, article) > > about the runtime Go code? > > Not really. It changes pretty quickly so any such docs would be more > or less out of date. > > > > I am specially interested in anything that describes the Golang runtime > > language subset restrictions: > > Mostly the code is written carefully by people who understand the > compiler. > > > > How does it avoid the GC? (while it's implementing it) > > By not allocating memory. It is helped by a "secret" compiler option, > -+. When that compiler option is used, the compiler gives an error > for any implicit memory allocation. Note that this is not a change to > the language, it is, as you say, a subset of the language: operations > that implicitly allocate memory are forbidden. > > What is the difference between -+ and -m for checking whether or not a variable "escapes to heap"? It looks the -m reports much more escapes than -+.
> > > Uses the GC primitives it provides at a lower level? A kind of its own > > malloc/free? > > There is a kind of simple malloc (but not free) in the > `persistentalloc` function. > > > > Ensures all is in the heap? > > Not sure what you mean there. > > > > Does it avoid goroutines as well? how? Uses plain threads directly? > > The runtime avoids goroutines (except in a few places) by simply not > using the `go` statement. The runtime uses plain threads to implement > goroutines, but otherwise does not use threads. > > > What other restrictions apply compared to "userland" Golang? > > The code that handles stacks can not itself use unlimited stack space. > The linker checks that it lives within the limited bounds available. > > > Why wouldn't the runtime subset be suitable for OS internals or > real-time? > > It could be. > > > Why wouldn't it be interesting to define a GolangRT subset language > > formally? > > It's a fairly limited language. I'm not sure why anybody would want > to use it if they weren't already using Go. > > 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.
