Miss Dada  🏳️‍⚧️

Whoa.https://twitter.com/pcwalton/status/1273340524838047744 …

However, Go still has no generational garbage collector with bump allocation.

You’ll fix it eventually :)

I'm sure you saw it but for others: https://blog.golang.org/ismmkeynote  "It isn't that the generational hypothesis isn't true for Go, it's just that the young objects live and die young on the stack. The result is [...] much less effective than you might find in other managed runtime[s]"

If this were true then you wouldn’t see so much performance tuning for allocations in Go. There are a lot of cases in which escape analysis falls down (e.g. closures). Go leaves like 100x allocation performance on the table for no real reason.

At present, it’s not for no reason. The runtime and standard library take advantage of values having stable addresses. These things could be overcome, but they have their own new associated cost. Having built a bump-alloc-gen-gc with capi before, it’s certainly it’s own beast.

Yeah, the JS team went through a multi-year process removing dependencies on stable addresses. The results were a win in the end, but it was certainly a LOT of work. (In my mind that’s the best reason to not do moving GC: it may be too much work for the gain right now.)

That being said, there are some really interesting designs that allow for address pinning and the ability to move values. @tenderlove has been doing great work/research on Ruby for that, my own work using the Immix GC is similar.