On Wed, Jun 24, 2020 at 5:28 PM <[email protected]> wrote:
>
> 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?

That doesn't sound like an accurate description of how the memory
allocator behaves.  It doesn't sweep an arbitrary number of spans.  In
the current implementation, on the slow path, it looks through a
limited number of spans to find one that has space, and then it sweeps
that one and uses it.  It checks up to 100 spans looking for one to
sweep; if it doesn't find any in the first 100 that it checks, it
allocates a new span.  So, yes, there is an upper bound on allocation
time.

Pretty much every time that the garbage collection developers find a
place where there is unbounded latency in the memory allocator or the
GC pause time, they fix it.  It's hard to be completely sure that
there aren't any left, but if there are any they are very unusual
cases.

Ian

-- 
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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVjdCidmE-%2BcZQmh1P4gQmGMv7jD64kwh4-apjX3K1mKA%40mail.gmail.com.

Reply via email to