)]}'
{
  "commit": "ae3bb4a537c84e43be2ed7b79e84450332aafe2d",
  "tree": "3caa28c5dfb2b4a3265c854f12d3d0cbd43872a0",
  "parents": [
    "f4dcc9b29b052b99b97d0e445cda589f08bfc798"
  ],
  "author": {
    "name": "Austin Clements",
    "email": "austin@google.com",
    "time": "Sun Sep 25 17:12:43 2016 -0400"
  },
  "committer": {
    "name": "Austin Clements",
    "email": "austin@google.com",
    "time": "Fri Oct 28 18:20:23 2016 +0000"
  },
  "message": "runtime: make fixalloc zero allocations on reuse\n\nCurrently fixalloc does not zero memory it reuses. This is dangerous\nwith the hybrid barrier if the type may contain heap pointers, since\nit may cause us to observe a dead heap pointer on reuse. It\u0027s also\nerror-prone since it\u0027s the only allocator that doesn\u0027t zero on\nallocation (mallocgc of course zeroes, but so do persistentalloc and\nsysAlloc). It\u0027s also largely pointless: for mcache, the caller\nimmediately memclrs the allocation; and the two specials types are\ntiny so there\u0027s no real cost to zeroing them.\n\nChange fixalloc to zero allocations by default.\n\nThe only type we don\u0027t zero by default is mspan. This actually\nrequires that the spsn\u0027s sweepgen survive across freeing and\nreallocating a span. If we were to zero it, the following race would\nbe possible:\n\n1. The current sweepgen is 2. Span s is on the unswept list.\n\n2. Direct sweeping sweeps span s, finds it\u0027s all free, and releases s\n   to the fixalloc.\n\n3. Thread 1 allocates s from fixalloc. Suppose this zeros s, including\n   s.sweepgen.\n\n4. Thread 1 calls s.init, which sets s.state to _MSpanDead.\n\n5. On thread 2, background sweeping comes across span s in allspans\n   and cas\u0027s s.sweepgen from 0 (sg-2) to 1 (sg-1). Now it thinks it\n   owns it for sweeping. 6. Thread 1 continues initializing s.\n   Everything breaks.\n\nI would like to fix this because it\u0027s obviously confusing, but it\u0027s a\nsubtle enough problem that I\u0027m leaving it alone for now. The solution\nmay be to skip sweepgen 0, but then we have to think about wrap-around\nmuch more carefully.\n\nUpdates #17503.\n\nChange-Id: Ie08691feed3abbb06a31381b94beb0a2e36a0613\nReviewed-on: https://go-review.googlesource.com/31368\nReviewed-by: Keith Randall \u003ckhr@golang.org\u003e\nReviewed-by: Rick Hudson \u003crlh@golang.org\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "e85535ea9f449db4b6b3a4f4eb14649f6454bf3a",
      "old_mode": 33188,
      "old_path": "src/runtime/malloc.go",
      "new_id": "c5f6facc4d513eff9e747216323190e9a2c1c9f8",
      "new_mode": 33188,
      "new_path": "src/runtime/malloc.go"
    },
    {
      "type": "modify",
      "old_id": "38d5492df105cd19a2c10bb4310a5485fcc1c3d3",
      "old_mode": 33188,
      "old_path": "src/runtime/mcache.go",
      "new_id": "c483310cee7597de88db13658a19c48bd7305078",
      "new_mode": 33188,
      "new_path": "src/runtime/mcache.go"
    },
    {
      "type": "modify",
      "old_id": "0e56efb9239690de79a0afe9a4410dcec0e807a6",
      "old_mode": 33188,
      "old_path": "src/runtime/mfixalloc.go",
      "new_id": "0d3d895113755632b84142eb793c07440cca277f",
      "new_mode": 33188,
      "new_path": "src/runtime/mfixalloc.go"
    },
    {
      "type": "modify",
      "old_id": "d17363261e266227142e1afec2650166971ffd9e",
      "old_mode": 33188,
      "old_path": "src/runtime/mheap.go",
      "new_id": "e81e410ad8867ab8b34a81f385d136c8c46ce4c0",
      "new_mode": 33188,
      "new_path": "src/runtime/mheap.go"
    }
  ]
}