8231603: (se) Selector implementations do not need to use cancelledKeys

[Chris Hegarty]

> On 1 Oct 2019, at 15:48, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> This is a change to the Selector and SelectionKey::cancel implementations to avoid needing the cancelled-key set. Although specified, the cancelled-set key is not exposed in the API (except in implementations of AbstractSelector where the implementation has access to its own cancelled-key set) so the change should not be observable. The change has no impact on alternative implementations of AbstractSelector.  While in the area, I replaced the use of AtomicBoolean for the open state with a VarHandle.  I also inverted the valid flag in SelectionKeyImpl to that its initial value is false and so doesn't need to be initialized to true with a volatile write.
> 
> http://cr.openjdk.java.net/~alanb/8231603/webrev/index.html

Seems fine to me. ( I agree that the change should not really be observable )

I assume that the kind of access operations that the selector does, add keys & iterate over all keys, are more suited to a deque, and therefore faster ( than HashSet ).

The updates from j.u.c.atomic to VarHandle look fine too.

-Chris.