NIO.2 and GC activity

[Leon Finker]

FYI, I did some performance testing across two machines (Windows Vista over
Wi-Fi connection) with single outstanding read and multiple outstanding
reads and writes on a socket. For single case I did this in Java NIO2 and
.NET. The code between the two is basically identical. The performance is
about the same. For multiple case I only did this in .NET since Java NIO2
prevents me from doing this. I see ~25% increase in data throughput in
multiple reads and writes case. And I did not even try to optimize the code
for re-sequencing multiple outstanding receives (just took a coarse grained
lock to protect shared state). This is with single client connection to a
server. I don't know if there will be any gains in Java NIO2, but it would
be nice to test it. If there is, then I would vote for removing the check
for multiple outstanding reads.

-----Original Message-----
From: nio-dev-bounces at openjdk.java.net
[mailto:nio-dev-bounces at openjdk.java.net] On Behalf Of Leon Finker
Sent: Friday, April 17, 2009 10:54 AM
To: 'Salter, Thomas A'; nio-dev at openjdk.java.net
Subject: RE: NIO.2 and GC activity

That's the whole issue: the order of multiple simultaneous read completions
on the same socket or file *are not guaranteed* when it ends up in the user
code. Even in MSDN for WSARecv they say that order is not guaranteed in this
case. But they also do not prevent/forbid programmers from doing this. They
even recommend this in Microsoft books (i.e.: Concurrent Programming on
Windows, and I can't remember all the other references where I learned
this). The order can be re-sequenced by programmer on read completions by
first associating a sequence number with scheduled reads. This has been done
for high throughput servers. I don't know if public source reference exists
or not.

Having multiple outstanding requests on socket/file can increase
utilization, leading to overall speedup. For example, multiple outstanding
disk I/Os can allow the I/O subsystem to optimize the movement of the hard
disk arm to reduce seek time (adjacent reads can be merged by file manager,
reads can be sorted by location on disk, etc).  In sockets case, it can
allow to skip extra buffering in driver/winsock2 and write directly to user
supplied buffer as data is ready thus reducing delays for real-time servers
(market data).

-----Original Message-----
From: nio-dev-bounces at openjdk.java.net
[mailto:nio-dev-bounces at openjdk.java.net] On Behalf Of Salter, Thomas A
Sent: Friday, April 17, 2009 10:08 AM
To: nio-dev at openjdk.java.net
Subject: RE: NIO.2 and GC activity

I couldn't find any MSDN reference that guarantees the order in which
multiple pending receives would complete.  Do they promise to satisfy
requests in the order they are issued?  Do they guarantee to post completion
status in the order the data is received?  I would certainly want to see
this spelled out in Windows documentation before writing an application that
depended on a particular order.  The cited MSDN Magazine article is 9 years
and 2 OS releases old and it only makes a passing reference to multiple
pending receives with no guidance on how to order the data.



-----Original Message-----
From: nio-dev-bounces at openjdk.java.net
[mailto:nio-dev-bounces at openjdk.java.net] On Behalf Of Alan Bateman
Sent: Friday, April 17, 2009 4:05 AM
To: Leon Finker
Cc: nio-dev at openjdk.java.net
Subject: Re: NIO.2 and GC activity

Leon Finker wrote:
> I agree there is no advantage for the writes, and I don't advocate it.
> On the reads I disagree that the order can't be guaranteed or
> re-sequenced on completion/failure. One is always able to re-establish
> the original order of reads that were scheduled on their completion or
> failure simply by associating the counter with the scheduled reads and
> then re-establishing the sequence. Yes, one has to be aware that if
> they schedule a read on non I/O windows pool thread and thread
> immediately exits, the I/O request will be canceled. But this applies
> to current NIO.2 implementation even with non simultaneous reads.
Our implementation never initiates I/O operations on non-pooled threads.
Instead, if a non-pooled thread invokes read/write it will be queued (via a
message posted to the completion port) so that it is initiated on a pooled
thread. That is where the ordering becomes undefined. Another case is where
a pool thread associated with one group initiates an I/O operation on a
channel associated with a different group.

> I agree the code is somewhat involved, and one has to deal with
> concurrency, but it's an option for core communication framework
> libraries out there. This optimization is not for every case, it's for
> specific communication/protocol patterns. So, I'm not sure if
> comparison will be fair. It's just a suggestion based on experience.
> If there is no need for this from the community, then you're right it can
be added later.
>
Yes, this is something for later once people have more experience using the
API.

-Alan.