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

[Chris Hegarty]

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.