3 ms·

Wait, Go doesn't compact? Is it safe to assume that they have to deal with fragmentation or does Go solve that another way?

nickcw 10y ago
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.
- vvanders 10y ago
  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.
  - krakensden 10y ago
    > has no manual mechanisms for allocation Golang supports value types for objects, so arrays (or something higher level like sync.Pool) work great for doing arena allocation.
- pcwalton 10y ago
  > 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 This is also the case in HotSpot.
geodel 10y ago
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. " 1. https://groups.google.com/d/msg/golang-nuts/Ahk-HunIqgs/1sOi8t5iCQAJ https://groups.google.com/d/msg/golang-nuts/Ahk-HunIqgs/1sOi...
- vvanders 10y ago
  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.

nickcw 10y ago

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.

vvanders 10y ago
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.
- krakensden 10y ago
  > has no manual mechanisms for allocation Golang supports value types for objects, so arrays (or something higher level like sync.Pool) work great for doing arena allocation.
pcwalton 10y ago
> 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 This is also the case in HotSpot.

geodel 10y ago

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. " 1. https://groups.google.com/d/msg/golang-nuts/Ahk-HunIqgs/1sOi8t5iCQAJ https://groups.google.com/d/msg/golang-nuts/Ahk-HunIqgs/1sOi...

vvanders 10y ago
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.