Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Golang's big miss on memory arenas

avittig.medium.com

Post reply on HN
Print view View original

1–10 of 157 posts

Re: Golang's big miss on memory arenas

#4

Post by convolvatron »

one question that always plagues me when we talk about mixing manual and automatic memory systems is...how does it work? if we have a mixed graph of automatic and manual objects, it seems like we dont have a choice except to have garbage collection enabled for everything and make a new root (call it the programmer) that keeps track of whether or not the object has been explicitly freed.

since we still have the tracing overhead and the same lifetimes, we haven't really gained that much by having manual memory.

D's best take at this is a compile-time assert that basically forbids us from allocating GC memory in the affected region (please correct me if I'm wrong), but that is pretty limited.

does anyone else have a good narrative for how this would work?

Re: Golang's big miss on memory arenas

#5

Post by catigula »

>If you choose TypeScript or Python, you’ll hit a performance wall the moment you venture outside of web apps, CRUD servers, and modeling.

This really isn't very accurate. It is for Python, but JavaScript is massively performant. It's so performant that you can write game loops in it provided you work around the garbage collector, which, as noted, is a foible golang shares.

The solution is the same, to pre-allocate memory.

Re: Golang's big miss on memory arenas

#7

Post by alexisread »

convolvatron wrote: post #4

one question that always plagues me when we talk about mixing manual and automatic memory systems is...how does it work? if we have a mixed graph of automatic and manual objects, it seems like we dont have a choice except to have garbage collection enabled for everything and make a new root (call it the programmer) that keeps track of whether or not the object has been explicitly freed. since we still have the tracin…

There are many automatic memory management systems ranging from the simple clearup of immutable systems (https://justine.lol/sectorlisp2/), to region allocation, to refcounting with cycle collection, and the full-fat tracing.

I'd have thought that allocating a block of memory per-GC type would work. As-per Rust you can use mainly one type of GC with a smaller section for eg. cyclic data allocated in a region, which can be torn down when no longer in use.

If you think about it like a kernel, you can have manual management in the core (eg. hard-realtime stuff), and GC in userland. The core can even time-slice the GC. Forth is particularly amenable as it uses stacks, so you can run with just that for most of the time.

Re: Golang's big miss on memory arenas

#8

Post by bluecalm »

Arenas is one of those patterns that very easy to underestimate. I didn't know about it when I started programming and I run into huge performance issue where I needed to deallocate a huge (sometimes tens of GBs consisting of millions of objects) structure just to make a new one. It was often faster to kill the process and start a new one but that had other downsides. At some point we added a simple hand written arena-like allocator and used it along with malloc. The arena was there for objects on that big structure that will all die at the same point and malloc was for all the other things.

The speed-up was impossible to measure because deallocation that used to take up to 30 seconds (especially after repeat cycles of allocating/deallocating) was now instant.

Even though we had very little experience it was trivial to do in C. Imo it's critical for performance oriented language to make using multiple allocators convenient. GC is a known performance killer but so is malloc in some circumstances.

Post reply on HN