7172826: (se) Selector based on the Solaris event port mechanism

[Alan Bateman]

I mentioned in a recent mail that I have a new Selector implementation 
for Solaris that uses the event port mechanism rather than the /dev/poll 
driver.  Joy Xiong from the Solaris performance team in Oracle has also 
been running various workloads with this Selector and is reporting good 
results, better in some cases.

The patch proposed here is to add this Selector, but without changing 
the default at this time. The default will continue to be the /dev/poll 
Selector and the java.nio.channels.spi.SelectorProvider system property 
can be used to select the event port Selector where needed. Once the new 
Selector has baked and we have more performance data, then we may 
consider changing the default. Another motivation to changing the 
default is that the /dev/poll is legacy and may go away in the future.

The Selector API was originally modeled on the poll interface and so 
doesn't map too well to I/O polling facilities that aren't level 
triggered. The way this implementation works is that after each poll 
(port_getn to retrieve multiple events) then the polled file descriptors 
are candidates for re-registration for the next poll. Changes to the 
interest ops will override this so that the file descriptor may be 
re-registered for different events, or not re-registered for cases where 
the interest ops are changed to 0 or the selection key is canceled. This 
seems to work better than optimistically re-registering all polled file 
descriptors immediately. One other difference compared to the other 
Selector implementations is the wakeup mechanism (Selector.wakeup) is 
implemented by sending a user event to the port rather than using the 
socket pair mechanism.

A couple of notes on the implementation:

1. For now sun.nio.ch.SolarisEventPort is changed to expose the event 
port API for the Selector implementation. Ideally the event port API 
would be factored out for use by the Selector and Asynchronous I/O 
implementations but that has ripple effects that would require renaming 
some classes. This can be done via a refactoring patch later.

2. The fdLimit method has moved from the Selectors to IOUtil so this 
requires minor adjustments in a few places.

3. The changes to the tests in the webrev are to allow the 
java.nio.channels.spi.SelectorProvider property be passed to tests via 
jtreg's -vmoption. Another idea is to add a script as a test that runs 
several of the existing tests with this Selector. We have alternative 
Selector implementations already, like the poll Selector that is our 
backup on Linux, Solaris and Mac and that could be tested in a similar way.

I think that's mostly it, the webrev with patch is here:

http://cr.openjdk.java.net/~alanb/7172826/webrev/

-Alan.