GC timing

[Eric S. Raymond]

Hal Murray <halmurray at sonic.net>:
> 
> >> That doesn't make sense.  Where does your "one second apart" come from?  
> Why
> >> is "currently has 2 threads" interesting?
> > When do we poll at a less than one-secpmd interval? Most allocatopmns wo;l;
> > ber associated with making a packet fra,e for he send, thn dealing with a
> > response that comes bacl less than 100ms later. 
> 
> I was thinking of the server side.  Pool servers can easily get 100s of 
> packets/second.  I assume that means we have to write the server side so that 
> it doesn't do any allocations.

At just 100s of packets per second I don't think there's any real problem
with dynamic allocation.  Taking 96 byters as a typical query length (that
includes auth and digest) let's round up to 1024 to account for allocation
overhead and to make the calculation convenient. 

A memory gigabyte is 2^20 of these packets.  That's 1048576 seconds of traffic,
or 291 hours, or 12 days and change.  Even if your system has just a GiB of
headroom, you're only going to trigger a GC due to queries about that often.
I don't think we get to numbers that even approach being worrying until
two magnitudes up from here.

> What is the API for recvfrom()?  Do you pass in a buffer, like in C, or does 
> it return a newly allocated buffer?

You pass in a buffer.  In theory we could maintain a buffer ring.  I'd want to
see actual benchmarks showing frequent GCs before I'd believe it was necessary,
though.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>