On Wednesday, March 22, 2017 at 6:00:12 PM UTC+8, Dave Cheney wrote: > > > > 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) >
But many heap pointers are not referenced by stacks. I guess each goroutine maintains an off-heap runtime data structures to store the heap pointers. > >> >>> 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.
