This is following from the changes to the NIO channels to refactor the async close/interrupt implementation (JDK-8198562. David Holmes points out a potential issue for code that invokes wait or sleep and immediately follows it with a blocking I/O operation may have an issue, e.g.

try { Thread.sleep(duration); } catch (InterruptedException e) { }
channel.read(buffer);

If the thread executing this code is interrupted then the interrupt status at around the same time that the above clears the interrupt status. If the above sets the blocker field for the read then it will cause the channel to be closed and end will close ClosedByInterruptedException without the interrupt status being set.

We need to restore this code so that it sets the interrupt status while holding blockerLock.