On Wednesday, 22 March 2017 20:51:18 UTC+11, T L wrote: > > > > On Wednesday, March 22, 2017 at 4:56:28 PM UTC+8, Dave Cheney wrote: >> >> 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. >> > > Thanks for the link. > > I was just curious on where heap pointers of local allocated memory blocks > are stored. > So there is the third kind of root, off-heap runtime data structures, to > store heap pointers of local allocated memory blocks. >
There are various memory structures that are not managed by the garbage collector. The native stacks for operating system threads are an example. They are invisible to the garbage collector for obvious reasons. > > >> But from the POV of a programmer, it's globals, and things reachable from >> each goroutine's stack. >> > > More accurately, I think it should be: from the POV of a programmer, it's > globals, and things reachable from each goroutine. > Which is package level variables visible to all goroutines and values on each goroutines's stack (as they cannot see values on another 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
