> On the contrary: do people roll good implementations of data structures usually?
In high-level languages, my general observation is that hand-rolled data structures can be divided into two kinds: the kind written by somebody who has no clue what they're doing, and the kind written by a data structures wizard that leaves you in awe about the details.
The most notable example of I've seen of the latter kind was in some read-optimised database where they wrote a cache that linearly scales with the number of readers almost infinitely -- some black magic with maintaining two copies of a map, and having each reader go through completely wait-free paths and switching maps on writes so they never interfere, whilst sharing the underlying storage to not make writes completely inefficient. Stuff like this just makes admire the crazy things that are possible.
Then you have the crappy linked list implementation #82432 that segfaults it you look at it funny.
> The Biscuit paper states "the longest single GC-related pause suffered by NGINX was 115 microseconds"; I'm not sure how well that generalises to other workloads, but (infrequent already) pauses would be hard to notice if that does generalise
> The collector suspends
ordinary execution on all cores (a “stop-the-world” pause)
twice during a collection: at the beginning to enable the
write barrier on all cores and at the end to check that all
objects have been marked. These stop-the-world pauses
typically last dozens of microseconds
Yeah that certainly seems to be the case, for interactive use, I find it hard to believe that anything less than a few ms will cause issues, and that's 3 orders of magnitude more than what biscuit found.
Although I do wonder if there are GC concerns elsewhere -- these are just vague memories, but I believe that the Go GC is pretty conservative and will not reap anything that looks like a pointer, so there might be concerns around leaks especially with all the special pcie registers, dma buffers, etc that might be lying around in memory.