Improving perf of FileChannel.transferTo() on Windows

[Alan Bateman]

On 11/11/2014 18:04, Kirk Shoop (MS OPEN TECH) wrote:
>
>
> Valery applied both of your suggestions and was able to run the jtreg 
> tests with this new webrev:
>
> https://openjdkcontrib.blob.core.windows.net/transferto/webrev-20141111.zip
>
>
I think this looks much better.

One thing that needs a closer look is the loop around TransmitFile. If 
it fails on the second or subsequent call then transferTo will fail 
after already sending transmitting bytes. For transferTo then it's okay 
to complete without having transmitted all bytes and maybe it would be 
better to just cap it at 2GB. Any robust code using transferTo should 
check the return value. (BTW: You can use java_lang_Integer_MAX_VALUE to 
avoid the repeating the constant).

In transferToDirectly then I don't think you need to check if the target 
is a SelectableChannel if you move call to nd.canTransferToDirectly to 
just above where it handles SelChImpl.

One suggestion is to top transferToDirectlyEnabledand instead jave 
canTransferToDirectlyreturn true then the property is enabled and the 
target change is SelectableChannel configured blocking.

A minor comment is that transferToDirectlyChangesChannelPositionis a bit 
inconsistent with methods like needPositionLock so you might be able to 
come up with something a bit closer to that, 
transferDirectNeedsPositionLock maybe?

A few style/formatting issues that we can sort out later, otherwise the 
approach looks okay to me.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20141113/906aaa99/attachment.html>