RFR: 8307425 - Socket input stream read burns CPU cycles with back-to-back poll(0) calls

[olivergillespie]

On Thu, 4 May 2023 17:15:59 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> One general comment on this, at least for Socket, is that a timeout of small number of millis seems a bit odd. I wonder if there is something else that is using the timeout exception for control flow.

Yes, two notes:

1. This affects longer timeouts too, assuming the timeout is hit. My example in the PR description uses 2 milliseconds to show the general pattern - the first n-1 milliseconds will be covered in one poll, then the remaining (just under) millisecond is spent in the tight loop. So it's really more like 1ms of tight looping per timeout, no matter the value.
2. The particular pattern I saw where this stood out was from Apache's (older, 3.x) HttpClient, using a 1ms timeout to check for 'stale' connections [here](http://svn.apache.org/viewvc/httpcomponents/oac.hc3x/trunk/src/java/org/apache/commons/httpclient/HttpConnection.java?view=markup#l504).

> we have to do similar changes in "DatagramChannelImpl" as well.

Thanks for spotting, my grep didn't find it because it uses a slightly different syntax. Will include that.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13798#issuecomment-1535966199