2

Does the Go GC move heap-objects?
I found some articles that say it does, but in the sync package, there is the copyChecker type, which could only work if the GC never moves memory.

Comments
  • 1
    Why do you care?

    Works? don't touch. or you get garbage all over you...

    And it must move the pages around. otherwise the heap will always grow, and never get smaller...
  • 0
    @magicMirror and the heap fragmentation doesn't sound very tempting as well I think. Having OOME when only 70% of heap is consumed. [speaking from java's perspective, but I guess GO has the same problems to solve]
  • 0
    @magicMirror
    Largely because c interop.
    The Go-runtime normally forbids storing go-pointers in c-memory.
    However, there is no reason stated why it's forbidden.

    Besides that, I found a comment in the Go sources stating, that the GC is, indeed, non-compacting.
  • 1
    @metamourge @netikras
    fuck it then.
    I already did a review on the android GC in ART, and Dalvik.

    Lets review the code in GO then. Now, where did I put that shnorkel....
  • 0
    tri color, non compacting, non generational.... prefer value arrays instead of pointers arrays... prefer thread local over globals....

    500ms gc runs.

    More reading required.
  • 0
    @metamourge storing go ptr, in c memory?
    thats a seg fault waiting to happen.

    Go has no way to track the pointers. so if an object has no root - it will be collected. C will try to access - seg fault.
    Otherwise - you just created a new permanent root. That will never be released.
Add Comment