Beware of drawing conclusions about generational GC from the Golang ISMM keynote. As far as I can tell, they didn’t test against copying generational GC with bump allocation in the nursery, which is the typical implementation.
-
-
I agree bump allocation is fast. I disagree that Go's malloc is "too slow". I believe the people manually adjusting their code to satisfy the escape analysis is the minority engaged in significant performance work.
-
It’s a minority of people, sure, but why make their lives harder?
- 1 more reply
New conversation -
-
-
The Go GC has FFI constraints. Java needs a fast allocator due to type-erasure and polymorphic containers. One can afford an allocator that is an order of magnitude slower if one can allocate an array of structs. Pointer chasing is not very cache friendly and JNI is horrible.
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
Is the FFI problem for a copying GC solved? Last time I looked at JNI it was like writing Java in long-hand via a clumsy C API. If everything is in GC-land, then a pause-less concurrent copying and collecting generational GC makes more sense.
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.