From the interesting keynote from the International Symposium on Memory Management (ISMM) on June 18, 2018:
Again we kept knocking off these O(heap size) stop the world processes. We are talking about an 18Gbyte heap here. We had much larger heaps and as we knocked off these O(heap size) stop the world pauses, the size of the heap could obviously grow considerable without impacting latency. So this was a bit of a help in 1.7.
That dropped us into the sub-millisecond range. Again the Y axis is about to change to 1.5 milliseconds and we see our third order of magnitude improvement.
We know what is causing the remaining pauses. The SLO whisper number here is around 100-200 microseconds and we will push towards that. If you see anything over a couple hundred microseconds then we really want to talk to you and figure out whether it fits into the stuff we know about or whether it is something new we haven’t looked into. In any case there seems to be little call for lower latency. It is important to note these latency levels can happen for a wide variety of non-GC reasons and as the saying goes “You don’t have to be faster than the bear, you just have to be faster than the guy next to you.”
There was no substantial change in the Feb’18 1.10 release just some clean-up and chasing corner cases.
We now have an objective of 500 microseconds stop the world pause per GC cycle. Perhaps a little sandbagging here.
Again this is not an SLA but an SLO so it’s an objective, not an agreement, since we can’t control such things as the OS.
P.S. The Go team is looking to hire engineers to help develop and maintain the Go runtime and compiler toolchain.
A. Now, I really like what mainly our one Julia guy has done regarding Julia’s GC. I don’t have any numbers, is Julia’s GC still competitive?
I know you can call Go (or from Go). I believe as with calling Java, then you have two runtimes and both with their own GC. While I don’t like Go as a language, I do like what their GC work (and some more). Does it make sense to compile Julia to Go?
We already have work for static compilation, with compiling to Go you get that for free (and they already have “gomobile build” that compiles the same Go codebase to either Android (generates APK) or iOS. I would like Julia to target both (at least Android) somehow.
B. They also do good work with concurrency, while not with race condition safety (then e.g. Rust is better). I believe neither does Julia have such safety… Would Julia’s code map well to their infrastructure? They have e.g. many stacks (thousands), is this a problem? I believe we have better FFI, but we could map to theirs and take a small speed penalty?
They also can now compile to WebAssembly.