Targets
The major target of this issue is to reduce execution time of ChannelInputStream::skip(long). In particular, make skip(n) run considerably faster than read(new byte[n]) on pipes and sockets in the optimal case, but don't run noticable slower in the worst case.
A side target of this issue is to provide unit testing for ChannelInputStream::skip(long). In particular, provide unit testing for files, pipes and sockets.
An appreciated benefit of this issue is reduced resource consumption (in the sense of CPU cycles, Java Heap, power consumption, CO2 footprint, etc.) of ChannelInputStream::skip(long). Albeit, as it is not a target, this was not acitvely monitored.
Non-Targets
It is not a target to improve any other methods of the mentioned or any other class. Such changes should go in separate issues.
It is not a target to add any new public APIs. The public API shall be kept unchanged. All changes implied by the current improvement shall be purely internal to OpenJDK.
It is not a target to improve other source types besides pipes and sockets.
Description
What users expect from InputStream::skip, besides comfort, is "at least some" measurable benefit over InputStream::read. Otherwise skipping instead of reading makes no sense to users.
For files, OpenJDK already applies an effective seek-based optimization. For pipes and sockets, benefits were neglectible so far, as skip more or less was simply an alias for read.
Hence, this issue proposes optimized implementations for ChannelInputStream::skip in the pipes and sockets cases.
In particular, the proposal is to implement skip using splice on Linux, and using C-loops elsewhere.
The major target of this issue is to reduce execution time of ChannelInputStream::skip(long). In particular, make skip(n) run considerably faster than read(new byte[n]) on pipes and sockets in the optimal case, but don't run noticable slower in the worst case.
A side target of this issue is to provide unit testing for ChannelInputStream::skip(long). In particular, provide unit testing for files, pipes and sockets.
An appreciated benefit of this issue is reduced resource consumption (in the sense of CPU cycles, Java Heap, power consumption, CO2 footprint, etc.) of ChannelInputStream::skip(long). Albeit, as it is not a target, this was not acitvely monitored.
Non-Targets
It is not a target to improve any other methods of the mentioned or any other class. Such changes should go in separate issues.
It is not a target to add any new public APIs. The public API shall be kept unchanged. All changes implied by the current improvement shall be purely internal to OpenJDK.
It is not a target to improve other source types besides pipes and sockets.
Description
What users expect from InputStream::skip, besides comfort, is "at least some" measurable benefit over InputStream::read. Otherwise skipping instead of reading makes no sense to users.
For files, OpenJDK already applies an effective seek-based optimization. For pipes and sockets, benefits were neglectible so far, as skip more or less was simply an alias for read.
Hence, this issue proposes optimized implementations for ChannelInputStream::skip in the pipes and sockets cases.
In particular, the proposal is to implement skip using splice on Linux, and using C-loops elsewhere.
- relates to
-
JDK-8303934 (fc) Use splice in FileChannel::transferFrom when the source is a pipe (Linux)
-
- Open
-
- links to
-
Review(master)
openjdk/jdk/20489