Conversation

Important but little-noticed effect of having a GC'd language: It forces the language devs to optimize memory allocation, because the language users can't do it themselves (at least, not nearly as easily). Lots of C++ users don't realize how fast malloc is in e.g. Java.

134

Replying to

I'm not sure if this is "pro-GC'd languge" or "anti-GC'd language", but C++ programs would probably spend ~25% less time in the allocator if it were tightly incorporated with the language runtime. (More if including sized deallocation, which most programs aren't compiled to use).

Replying to

Agreed. I would like to start stuff in Rust like inlining allocator fast paths...

Replying to

and

Mandatory sized deallocation (like Rust's API) also provides substantial advantages over it being optional. The design of the allocator can be substantially different if it doesn't have to deal with figuring out the size.

Replying to

and

github.com/GrapheneOS/har is entirely focused on security but some of the concepts it uses would be very useful for a much different performance-oriented allocation design. On 64-bit you can reserve tons of address space as PROT_NONE even without overcommit and that changes things.

github.com

GitHub - GrapheneOS/hardened_malloc: Hardened allocator designed for modern systems. It has...

Hardened allocator designed for modern systems. It has integration into Android's Bionic libc and can be used externally with musl and glibc as a dynamic library for use on other Linux-base...

Replying to

and

I don't see a good equivalent to libdivide.com for Rust (good use case for CFE) but the approach is really useful. If you do it very efficiently, bitmaps for slabs and array-based thread/CPU caches can be more efficient than free lists due to data locality.

4:04 AM · Feb 12, 2021Twitter Web App

Likes