Here is what Ian lance Taylor has to say about fragmentation[1]
"Heap fragmentation is not normally a concern with the current Go runtime. The heap is implemented to that large pages are divided up into blocks that are all the same size. This means that the usual definition of fragmentation--a small block prevents coalescing of large blocks--can not occur. "
That's not any different than most C malloc implementations, it certainly helps with fragmentation but doesn't eliminate it as a concern. You can still have a single allocation in a block that'll hold the whole block hostage.
I'm used to systems that vary from 8-512mb of total system ram with no virtual memory. Techniques that work well on the desktop/server explode spectacularly when brought to our platforms.
I believe that fragmentation isn't such a problem in Go programs because they make less use of the heap than Java programs. I can't remember where I read this though.
I don't know much about the internals of Java, but I know that Go will stack allocate any kind of object if the compiler can prove it doesn't escape, and that in Go lots of things (not just native types) are passed by value on the stack instead of by reference to a heap value.
Sure, I guess I'm just floored that you'd have a system that doesn't compact and has no manual mechanisms for allocation.
I guess it's just a different class of problems that I'm used to dealing with. Fragmentation is something I've seen many times and it usually likes to rear it's head at the worst possible moment.
Is it safe to assume that they have to deal with fragmentation or does Go solve that another way?