1. 7

  2. 2

    A puzzle I asked the author about there: Go should avoid scanning allocations it knows will be empty of pointers (either actual *Foo or the types represented with pointers internally), which should mean very low GC time, but the author tried to apply that and it didn’t help.

    I wonder if it’s that some other GC step (sweep, or the ‘scavenge’ step that returns RAM to the OS) gets slow with huge heaps, if it was something specific to the particular program (pointer hiding somewhere), or if it’s somehow a bug with noscan behavior itself. Interested because if you can make GC cheap by doing big noscan allocations, then you get your performance win while sticking to allocating with the usual language constructs.

    1. 1

      Sounds like they increased system complexity to fix something that wasn’t even a problem.