Improving perf of FileChannel.transferTo() on Windows
Kirk Shoop (MS OPEN TECH)
Kirk.Shoop at microsoft.com
Fri Nov 14 16:51:43 UTC 2014
From: Alan Bateman [mailto:Alan.Bateman at oracle.com]
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).
Good point, Valery removed the loop.
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 transferToDirectlyEnabled and instead jave canTransferToDirectly return true then the property is enabled and the target change is SelectableChannel configured blocking.
A minor comment is that transferToDirectlyChangesChannelPosition is a bit inconsistent with methods like needPositionLock so you might be able to come up with something a bit closer to that, transferDirectNeedsPositionLock maybe?
Valery chose 'transferToDirectlyNeedsPositionRestoring', but this can be changed.
While looking at this, I wondered, could the position lock and position manipulation in Java be skipped altogether if 'Java_sun_nio_ch_FileChannelImpl_transferTo0' used 'Java_sun_nio_ch_FileChannelImpl_position0' to restore the position to the original point?
A few style/formatting issues that we can sort out later, otherwise the approach looks okay to me.
Happy to take those changes anytime.
Here is the new webrev:
Microsoft Open Technologies, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the nio-dev