The comment on https://github.com/golang/go/blob/master/src/runtime/mgc.go#L47
// c. GC performs root marking jobs. This includes scanning all // stacks, shading all globals, and shading any heap pointers in // off-heap runtime data structures. Scanning a stack stops a // goroutine, shades any pointers found on its stack, and then // resumes the goroutine. Suggests there are a few runtime internal data structures. But from the POV of a programmer, it's globals, and things reachable from each goroutine's stack. On Wednesday, 22 March 2017 19:51:40 UTC+11, T L wrote: > > > > On Wednesday, March 22, 2017 at 4:33:21 PM UTC+8, Dave Cheney wrote: >> >> >> >> On Wednesday, 22 March 2017 19:29:02 UTC+11, T L wrote: >>> >>> >>> >>> On Wednesday, March 22, 2017 at 4:08:02 PM UTC+8, Dave Cheney wrote: >>>> >>>> >>>> >>>> On Wednesday, 22 March 2017 19:04:36 UTC+11, T L wrote: >>>>> >>>>> In this article: https://blog.golang.org/go15gc , it mentions >>>>> >>>>> ..., The GC visits all *roots*, which are objects directly accessible >>>>>> by the application such as globals and things on the stack, and colors >>>>>> these grey. ... >>>>> >>>>> >>>>> It lists two kinds of root objects: globals and objects on stacks. >>>>> My question is how objects on heap will be visited? >>>>> >>>> >>>> By walking the heap (there are some optimisations to avoid areas of >>>> memory where no objects are known to be stored) >>>> >>> >>> Walking the heap is at collecting stage? Will the heap be walked at >>> analyzing stage? >>> >> >> Garbage collection has two main phases; mark and sweep. The heap is >> walked during the marking phase. >> >>> >>> >>>> >>>> >>>>> For every object on heap, is it always been referenced by another >>>>> global object or another object on a stack? >>>>> >>>> >>>> Yes, otherwise it's garbage :) >>>> >>> >>> >> So when a memory block for a local object is allocated on heap, there >>> will be also a pointer, which stores the address of the memory block, >>> recorded on stack? >>> >> >> When memory is allocated on the heap, memory is allocated on the heap; >> that's it. The garbage collector records the details of the type of the >> allocation in the heap alongside the object for most* allocations. >> >> * for small allocations they go into their own areas; google slab >> allocator. >> >> So that the memory block on heap will be tracked from stack? >>> >> >> From any gc root. The point is if there is no path from a gc root to an >> area of memory on the heap, that area is unreachable and therefore can be >> reused. >> > > except globals and stack objects, are there any other roots? > > >> >> >>> >>> >> -- 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.
