JDK-6465310 : (fc) scatter/gather operations on non-direct buffers doesn't use buffer cache
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.nio
  • Affected Version: 5.0u8,6
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: solaris_1,windows_xp
  • CPU: x86,sparc
  • Submitted: 2006-08-29
  • Updated: 2013-11-01
  • Resolved: 2009-02-16
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
6u21Fixed 7Resolved
Related Reports
Duplicate :  
This is about scattering and gathering byte channel api. As per the java doc and
theory-wise, Scattering and Gathering needs to be more efficient than individual
read/write of bytebuffers to a channel.

Please a take a look at the example attached here. The example opens a temp file
and writes an array of bytebuffers to the temp file. this writing is done in
two ways to comapre the time to write using array index in a loop and using 
Gather api.  Seems like gather is spending too much time in create direct buffer.

current output :
../../java-se-6/build/solaris-sparc/bin/java Gather 1000
transfer by Gather: time=28562 ms
transfer by Array time=150 ms

Expected outout:
Time consumed by Gather should be atleast less than or equal to that of Array.

Problem is reproducible on any JDK (5 or 6) and always. 
Instructions to reproduce:
Supply the number of iterations (=~ number of bytebuffers in the array) as an arg. 
I used 1000 for my testing. There is another bug  that it will crash vm  if there is no
memory (..expected to see a oom)

EVALUATION This issue has been fixed as part of the changes in the NIO2/JSR-203 implementation.

EVALUATION The test case uses ByteBuffer.allocate to allocate the byte buffers and hence is using byte buffers that are backed by an array rather a direct buffer. If the test case is changed to use direct buffers (ByteBuffer.allocateDirect) then the performance issue goes away. The reason that the scatter/gather operations on non-direct buffers are "slow" is because the implementation is forced to copy the bytes into direct buffers and the scatter/gather implementation doesn't make use of the temporary buffer cache. It could be changed to make use of the cache but it may not be useful in cases where the number of buffers is large. In any case, this is something that we should just fix in jdk7.