IIRC, even interface conversions would potentially allocate memory. (Correct me if I am wrong. It might have been changed.)
And I wonder if the 'restrictions' can be checked through an external tool like 'go vet' or another rather than deep corners of the compiler? If so, that would be useful for some applications which need strict zero-allocation guarantee, or at least, giving hints for performance tuning. Considering that Go can do almost what C can do except maybe union in terms of the granularity of low-level control, I wouldn't say it's that useless. On Wednesday, January 25, 2017 at 4:40:29 PM UTC+8, josvazg wrote: > > Thanks a lot Ian, that gives me a big picture of it! > > To clarify my question about the heap, it was wrongly written; I meant to > say if all memory was kept in the stack (instead to the heap). You already > it answered anyway. > > Here are my takeaways (with a few questions): > > 1. 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. > 2. 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? > 3. 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? > - *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? > 4. 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. > 5. 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?* > - A set of active tasks, like the GC, that are basically 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? > 6. The stack size for the runtime is static. > 7. GolangRT subset language not only is fuzzy and changing, it is also > very limited to me generally useful for anything else. > > Thanks, > > Jose > > El martes, 24 de enero de 2017, 22:16:07 (UTC+1), Ian Lance Taylor > escribió: >> >> On Tue, Jan 24, 2017 at 12:46 PM, josvazg <jos...@gmail.com> 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. >> >> >> > 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.
