News for hackers. Stuff that matters.
Re:Serious Chrome zero-day by kllrnohj on Thursday March 07, 2019 @01:33PM (#19330692)
A fast GC doesn't mean the code wouldn't have been faster without a GC.

GC's prevent you from doing a huge range of techniques to improve cache locality or reduce allocation/free churn.

A simple example would be games will do things like have just a big allocation for all a frame's temporary data, and they just bump-pointer allocate from it. Then when the frame is over, they reset back to zero. It is already The Perfect GC. Bump pointer allocation, zero pause time, and perfectly consistent memory usage. No matter how good Go's GC gets it will always be slower than that.

At the other end of things you have things like LLVM's PointerUnion, where alignment requirements are (abused) to cram a type id into the lower bits of the pointer itself. Type-safe variant in the size of a void*.

Re:Serious Chrome zero-day by pjmlp on Friday March 08, 2019 @03:10AM (#19335954)
> GC's prevent you from doing a huge range of techniques to improve cache locality or reduce allocation/free churn.

This is only true in languages which don't provide other means of memory allocation.

D, Modula-3, Mesa/Cedar, Oberon variants, Eiffel, .NET all provide features for such techniques.