NIO usage in FS & Network api's
Submitted by epr on Thu, 11/04/2004 - 06:42.
Hi all,
I want to discuss the usage of the nio api in the context of our filesystems and network api's.
I think it is a good idea to change our existing api's in these areas in such a way that they use nio where possible.
These reasons for this area:
- It is a standard, why not use it
- It can give much better performance
- Better fit with current classpath implementation
What do you think.
- Login to post comments
NIO in FS : let's use ByteBuffer !
Hi ewout,
I really it can give better performance for FS. I have seen some stuff that could be optimized :
- alignments to begin of a block of a device, maybe to often
- and maybe unnecessary copy of blocks
Moreover, as I am working on a cache for block devices, I really need some stuff given by nio, specially the ByteBuffer class. It should replace byte[] because it can avoid unnecessary splits (so copy/allocation of blocks of memory).
And, last but not least, it's more object oriented.
Fabien
Please explain
Hi Fabien,
> specially the ByteBuffer class. It should replace byte[] because it
> can avoid unnecessary splits (so copy/allocation of blocks of memory).
What do you mean by this?
Andras
some explainations
Hi andras,
In the package java.io, the methods are using byte[] but we have no warranty that the data requested is starting at the begin of a device block and with size that is a multiple of a block size(1). And, genererally, it's not the case.
At the lower level (when communicating directly with the device), the data are ok (as specified in (1)).
But until the methods (that need byte[]) of the classes in the java.io package, we should delay as much as possible copy of data. Instead, we use are just changing the start and the length in ByteBuffer to match the data requested. Thus, we avoid allocating a new byte[] and copying data to it.
About splits, lets take an example :
- the user request 10 bytes
- the user request the following 345 bytes
If the block size is 512 bytes, from device API to the java.io API (called by the user), we have probably made unnecessary copies, specially if we use a cache of blocks (which is necessary for performances).
Of course, we must keep the compatibility with sun APIs, so byte[] are necessary in some methods. But, internally, we must use (where possible) the ByteBuffer class or a similar one.
Is it clearer ?
Fabien
In the networking API
With the new packet representation we can easily migrate to nio buffers. But it is a litle bit hard to intergrate them (the new packets) in the current networking framework. I am working on it, but not commited anything since 3 weeks, because the branch will be broken.
p.s: Very good topic. I like discussions about things that got to do with the general architecture of jnode.