Manual Memory Management in Go • Hacker News Board

Re: Manual Memory Management in Go

#11

Post by vvanders » Thu, May 14, 2015, 8:48 PM UTC

Usually when you want to manual memory management it's for two reasons:

1. You have more domain knowledge about the objects you're creating so you can special case and beat malloc()/free()(which can be extremely painful in some cases).

2. You need to control the memory layout of your objects so that the data access patters line up with memory layout. The speed improvements here are on the order of 50-100x depending on your case.

Usually(but not always) GC'd languages don't give you value types that let you do #2. C# and a few others happen to be a nice exception. If you're using Java you end up being out of luck unless you decided to leverage a library that provides views into byte buffers like FlatBuffers. Although then you pay the indirection costs.

I haven't worked much with Go to know if it supports composing values types like C# but when we talk about performance that's usually what crosses a lot of GC'd languages from my list.

Re: Manual Memory Management in Go

#12

Post by gillianseed » Thu, May 14, 2015, 8:53 PM UTC

plorkyeran wrote: post #7

jenandre wrote: post #4

"Imagine doing lots of small allocations - you can cause a lot of fragmentation resulting in needlessly having to resize your heap which in dire scenarios can result in thrashing." The article repeatedly talks about how managing memory manually increases the risk of fragmentation. And that this risk somehow goes away with gc managed heaps. ...so garbage collectors don't also have to manage their own internal heaps an…

Compacting garbage collectors don't have fragmentation issues, but of course Go doesn't have one. A GC isn't even strictly a prerequisite for compaction. Manually combining memory allocations to reduce allocator overhead and fragmentation is a lot of work, but not unheard of.

>Compacting garbage collectors don't have fragmentation issues

At the expensive cost of moving memory blocks around in the managed heap, there is no silver bullet.

Re: Manual Memory Management in Go

#13

Post by jdright » Thu, May 14, 2015, 8:58 PM UTC

As if managing memory manually was only the need of calling malloc and free at will. The problem with pro-GC is that they think the ones against it only want and like to do malloc and free for fun. Their simplist view of the issue is really as much annoying as they dismiss of the performance* issue.

*real-time, embedded and gamedev for example. where us scale have as much importance as ms for other fields.

Re: Manual Memory Management in Go

#14

Post by ridiculous_fish » Fri, May 15, 2015, 2:58 AM UTC

plorkyeran wrote: post #7

jenandre wrote: post #4

"Imagine doing lots of small allocations - you can cause a lot of fragmentation resulting in needlessly having to resize your heap which in dire scenarios can result in thrashing." The article repeatedly talks about how managing memory manually increases the risk of fragmentation. And that this risk somehow goes away with gc managed heaps. ...so garbage collectors don't also have to manage their own internal heaps an…

Compacting garbage collectors don't have fragmentation issues, but of course Go doesn't have one. A GC isn't even strictly a prerequisite for compaction. Manually combining memory allocations to reduce allocator overhead and fragmentation is a lot of work, but not unheard of.

The Classic Mac OS API (the "toolbox") had a compacting manual memory management scheme. Instead of raw pointers like what malloc might return, you worked with double-pointers called Handles (different from Win32 Handles), which indirected through a global Handle table. System calls may compact or rearrange the blocks of memory referenced by Handles. If you wanted to dereference the Handle across a system call, you had to HLock it to keep it from being moved, similar to object pinning in C#.

In modern OSes, virtual memory plays an analogous role. We still have a double indirection, but it goes through the TLB and page table.