Thanks for pointing this out. While it isn't clear how this is applicable to the sweep free alloc work it does seem relevant to the mark worker's heap tracing which can charitable be described as a cache smashing machine. The mark worker, loads an object from a random location in memory, scans it, drops pointers to other objects needing to be scanned into a buffer, and then does not visit the object's cache lines again. The loads evicts cache lines being used by goroutines and while a victim cache may help ameliorate the problem any cost we can move from a goroutine to the GC worker is a win.
Segregating the GC's cache lines from that of the go-routines should result in the goroutine's cache lines not being evicted and the GC evicting a cache line recently used by the GC. This seems like a good replacement policy. It certainly seems like a promising avenue. It's a build and measure. (and build and measure....) On Sunday, July 31, 2016 at 5:47:44 AM UTC-4, EduRam wrote: > > Hi! > > I am catching up some summer readings ... and recently came across this > article > about Intel Cache Allocation Technology (CAT), on Haswell processors > (http://lwn.net/Articles/694800/) > > > It appears it will be possible to allocate partial CPU L3 cache to > processes. > > > I remember reading about a new experiment on Go runtime GC allocation, > that would use more "cache friendly" bitmap. > ( > https://github.com/golang/proposal/blob/master/design/12800-sweep-free-alloc.md > ) > > > Just out of curiosity ... could this CAT mechanism, help further the GC > mechanism ? > I must confess this is outside my knowledge domain. Just reading for fun > of it. > > Thanks and great holidays, > > Edu > > > -- 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.
