Yeah but at least you don't end up with a fragmented heap.
-
-
-
That’s why you have a generational compacting GC with bump allocation in the nursery :)
- 1 more reply
New conversation -
-
-
This Tweet is unavailable.
-
I’m not talking about those; I’m talking about sync.Pool in Go.
- 1 more reply
-
-
-
Languages that let you mix GC'd and non-GC'd code are a thing too (i.e. D).
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
This Tweet is unavailable.
-
For a moving collector, GC cost is roughly linearly proportional to live heap size, because that’s what needs to be scanned (fairly bad for cache, even with prefetch) and copied to the surviving generation; pooling *can* help with this! But deallocation itself is fairly cheap
End of conversation
-
-
-
Nim (and I think D) let you tell the GC to stop tracking something. You can "retrack" it or free it later if you like but that's on you.
-
GC'ed ATS will let you track select objects with a linear type variable which forces you to manually free to consume it.
- 1 more reply
New conversation -
-
-
You can avoid it with compact regions I think? https://hackage.haskell.org/package/compact-0.1.0.1/docs/Data-Compact.html …
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.