Performance regression on jdk7u25 vs jdk7u40 due to EPollArrayWrapper.eventsLow

[Alan Bateman]

On 10/01/2014 00:43, Jungwoo Ha wrote:
> Hi,
>
> I found a performance issues on DaCapo tradesoap benchmark.
Thanks for mail and the analysis.

As Vitaly mentioned, the number of Selectors is typically small. However 
I will add that sometimes you can encounter cases where there are a lot 
of  "temporary Selectors", basically short lived and only used to select 
on a one channel. One of the main causes of temporary Selectors used to 
be the "socket adapters", basically the Socket you get when you invoke a 
SocketChannel's socket method. In JDK 7 and older then doing a timed 
connect or timed read with one of these Sockets involves the use of a 
temporary Selector. Temporary Selectors are cached (and so are long 
lived) so I wouldn't expect to see them allocated very often, unless of 
course tradesoap or some library that is used is doing this.

Do you have the environment/motivation to repeat the exercise with JDK 8 
to see if there is a different? JDK 8 eliminates the use of temporary 
Selectors and so might quickly answer the question as to whether the 
issue is temporary Selectors or not.

As regards the size of eventsLow (from your analysis) then there is an 
undocumented/unsupported system property that you could use in 
experiments. The property is sun.nio.ch.maxUpdateArraySize and it 
defaults to the file descriptor limit or 64k (whichever is smaller). 
 From your mail then I will guess that you might have the hard limit set 
to unlimited (or maybe 64k). So you would run with 
-Dsun.nio.ch.maxUpdateArraySize=8192 for example, just don't set it to a 
value larger than the hard limit.

-Alan.