Idea #1 on integrating RC with GC

[Sean Kelly]

On Saturday, 8 February 2014 at 16:41:42 UTC, Paulo Pinto wrote:
>
> In the stock exchange there are Java and .NET systems doing 
> transactions at faster speed than that.
>
> 100ms is too much money to be lost if the transaction course 
> changes.

It might be worth referring back to Don's talk at least year's D 
conference.  His company does targeted advertising, and if I 
remember correctly, their entire transaction response time limit 
including time on the wire is around 40ms.  It's small amounts 
rather than potentially millions per transaction, but either way, 
for many network services these days, profit is directly tied to 
exceedingly rapid response time.

Even for cloud services, let's say a user is willing to accept a 
500ms transaction time, including transport.  Now let's say the 
could service has to talk to 5 other services to process the 
request, each which has a normal transaction time of 50ms.  If 
one occasionally spikes to 250ms, that's a problem for that one 
request, but it's an even bigger problem for all the requests 
piling up behind it, since in this case the entire process is 
blocking on a garbage collection.  Under very heavy load, the 
process may not even be able to recover.  You can see this in 
Netty for Java, as it has a fixed request queue size (defaults to 
like 5) and once this limit is reached it just starts rejecting 
requests.  A long collection means request failures.