Ranter
Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Comments
-
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... -
@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]
-
@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. -
@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.... -
tri color, non compacting, non generational.... prefer value arrays instead of pointers arrays... prefer thread local over globals....
500ms gc runs.
More reading required. -
@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.
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.
question