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

[Seán Coffey]

Meant to get back on this also Alan. Look goods to me. Will be 
interesting to see how performance compares.

Minor format comment on EventPortSelectorImpl.doSelect(long) method 
(line 64-66).
Perhaps some javadoc style comments could be used in 
EventPortWrapper.java also. (again only minor)

thanks for looking after this.

regards,
Sean.

On 06/06/12 15:03, Chris Hegarty wrote:
> Nice work! Looks good to me.
>
> -Chris.
>
> On 03/06/2012 21:53, Alan Bateman wrote:
>>
>> 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.