I'm considering Go for a new service application and I'd like to minimize the time between a request being received and the response being sent (i.e., response latency). I like what I've read about all the work that's gone into the golang garbage collector to reduce stop-the-world pause times, but I've some concerns about the allocator performance. As I understand it, the Go collector never moves objects and so its allocator cannot use something like TLABs in Java (which support very fast allocation). From what I can tell, the Go allocator's fast path can only happen if there is a *swept* span with free objects. If the allocator needs to get a new span, it might end up having to sweep multiple spans until it encounters a span with free objects on it. This, to me, seems like a latent form of latency! I appreciate that the collector's STW events will be very short (proportional to the root set size), but I'm worried that my goroutine might try to allocate something and find itself sweeping an indeterminate number of spans before returning to service a request. Is there no upper bound on allocation time? or is this just not a problem in practice?
Thank you -- 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 golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/812feb15-d3df-4b9c-83d3-3e343fa08bdfo%40googlegroups.com.
