Replacing C

[Eric S. Raymond]

Hal Murray <hmurray at megapathdsl.net>:
> 
> esr at thyrsus.com said:
> > On the other hand, I don't consider requiring a runtime to be an *intrinsic*
> > disqualifier.  The real question is, in my view, the 95th-percentile length
> > of latency-inducing stop-the-world stalls. If it's below 100 microseconds
> > that is almost certainly good enough. 
> 
> What is "a runtime"?  How does it differ from something like libc?

A runtime is, in this context, a garbage collector that introduces occasional
stop-the-world latency spikes, and a thread multiplexer that supports concurrency
within the application language at the cost of some throughput.

> Is "95th-percentile" the right dimension?  How did you come up with 100 
> microseconds?

The underlying assumption is that the time distribution of latency spikes is...
I was going to say Gaussian but now that I think of it the logic works even
if the distribution is exponential or Erlangish.  If can't guarantee that a
GC spike will *never* introduce disruptive jitter, we can at least aim at
a maximum stop-the-world time that will *almost never* do it.

I chose a 100 microsecond target because that's short enough that it
probably induces jitter of less than 1ms, which is in turn probably
enough to keep us under the 10ms sustained accuracy I think people
consider normal these days.

> The API on the receive path gets a time stamp from the kernel so we don't 
> care about stalls there.  We do care about stalls on the transmit side.  That 
> path should be short and clean, but it gets tangled up with crypto so maybe 
> not.  If there is any level of predictability on the stalls, we should be 
> able to cooperate and avoid them in the critical sections.

Every once in a while you say something that rocks my world.  You just
did it again.

That was really incisive.  Furthermore it suggests a simple, effective
mitigation strategy - lock out GC on the transmit side.  Since most of the
computation happens before that, this should be practical.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>