I'm enthused. Clever but understandable, seems like a great fit for Go and
a lot of stuff folks build in it.
Am I guessing right that the single contiguous span is a simplification to
describe the idea, and there are still spans per size class, etc.? If so,
does that mean that a goroutine's min. footprint while running might
include a span for each size class it uses where they don't now? Seems fine
if so (we're still talking KBs and you get a lot in return), but could rate
a sentence in any eventual release notes, .
Something fun re: data being published in possibly surprising ways. The
net/http server uses a sync.Pool to get a pointer to a bufio.Writer likely
allocated by some other goroutine, and then sets the bufio.Writer's target
io.Writer to a chunkWriter for writing to the HTTP response. The
chunkWriter holds a pointer to the response, so it can reach request and
response headers, etc. So by using a *bufio.Writer that isn't in your local
spans, you prevent the TOC from collecting the whole request/response objs.
Not how big a deal that is in terms of bytes, but it's surprising behavior!
(Also, talking here about HTTP/1.1 code to be clear. Know h2 stuff is
intentionally communicating a lot.)
Here I see two workarounds. If you copy a bufio.Writer by value instead of
by pointer, now it really *is* in local memory and setting its Writer
doesn't publish anything. (If you're doing that you'd also need to reset
the target io.Writer to nil before returning it to the pool.) I imagine
something similar may come up in other situations--you *wish* some struct
were local but it's not, so you copy it and your wish comes true, heh. Or,
much simpler fix, but more specific to this situation, is to drop the
sync.Pools if TOC makes it cheap to just locally alloc a bufio.Writer per
Assuming this goes in, I am sort of curious what you guys' position winds
up being re: launching goroutines you otherwise wouldn't as a hint to the
collector, and curious if a runtime.LocalGC() will be exposed. I'm not sure
I have much to add on either.
Post by email@example.com
Over the course of the next several months we hope to implement, test,
optimize, and if the numbers warrent, deploy a brand new garbage collection
(GC) algorithm for Go. The Transaction Oriented Collector or TOC algorithm
will be integrated with and augment Go's current low latency collector.
golang.org/s/gctoc contains an overview, some informal proofs showing
correctness, and our implementation approach. Comments and suggestions
are always welcome.
You received this message because you are subscribed to the Google Groups "golang-dev" 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.