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 firstname.lastname@example.org.
For more options, visit https://groups.google.com/d/optout.