I'm considering how to allow performance optimization of memory freeing in Go; my current GC pause times for one application average 750 - 1500 msec, which makes these pauses a bit troublesome. It seems to me like programmers should be able to provide hints to the garbage collector. Often times I know I'm done with this block of memory, and my knowledge is currently wasted, resulting in long GC pauses.
What if there was a runtime.FreeMemory(*T) operation in Go, that depended on three states of the system:
In Sandboxed environments, runtime.FreeMemory() is a noop. That way it is impossible to crash the program in a sandbox by early free of memory.
In non-sandboxed environments, suppose we have (I'm making up a variable name:) unsafe.MemoryFreeAllowed = CHECK_FREE. If this variable is set to CHECK_FREE, then the garbage collector will simply note the FreeMemory() invocation stack trace, and on the next scan, if that memory was not in fact free, will panic with a report indicating that the FreeMemory() call was erroneous, and give the saved stack trace. The effect would be to allow the program to run with production loads, and to verify that, under those loads, the hints were always correct.
Finally, also in non-sandboxed environments, one can set the performance setting of unsafe.MemoryFreeAllowed = FREE_INSTANTLY. With FREE_INSTANTLY (also a non-zero not-default value), then the memory is freed immediately without waiting for GC to verify. This is unsafe, as it can crash your program, but could readily and radically reduce pause times when the programmer is providing correct FreeMemory() advice.
It's optional. It's safe when sandboxed. It lets Go venture into application territory that is owned by C++ currently.
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to