NIO.2 and GC activity

[Alan Bateman]

John Franey wrote:
>
> Folks,
>
> I only just became interested in nio 2, found this entry (Re: NIO.2 
> and GC activity <http://markmail.org/message/kjzxpqxhtplis7hv>).
>
> +1 for design decisions that can keep memory througput low.
>
> I've been load testing an RTP based media server.   I have found that 
> thread pauses are directly correlated to media quality.  Thread pauses 
> cause jitter (variance in delay between packets).
>
> When threads are active, packets can be sent at a constant rate with 
> low jitter.  But when threads are paused, there is a delay in one or 
> more of the packets.  For example, in a stream of packets at rate of 
> once every 20ms, a gc pause of 50ms would delay the immediate packet 
> by 30-50ms, and the following packet by up to 10ms.  These are 
> tolerable, AFAICT, but could be only a component of a larger jitter 
> detected at the receiving end.  I've verified the above by correlating 
> the thread pauses (from the gc log) with actual traffic using 
> tcpdump/wireshark.
>
> I think memory allocated per send/receive can eat up the heap pretty 
> quickly.  At 250 udp 'connections', exchanging 50 packets each way per 
> second, will add up to 25000 read and write requests per second.
>
> But, perhaps jvm will allocate Futures (retun type from read and 
> write) on the thread stack?
Changing the methods that have a completion handler as parameter to 
return void is probably the right thing to do. However,  as I said in a 
previous rely, this doesn't eliminate all object allocation as there are 
still cases where some objects are required (timers for example). A 
while back I did a number of tests but didn't observe any noticeable 
difference because the scavenging of the new generation was so fast.

So are your tests with AsynchronousDatagramChannel? Just curious because 
this is the odd one out in that it doesn't have a high performance 
implementation yet. Hopefully this will be in the repository soon.

-Alan.