Re: nio package and asynchronous io

[shudo]

From: Artur Biesiadowski <address@hidden>

> For me, most tricky parts of nio is Buffer. You have to extend JNI to
> enable them, make some special tricks in jvm to allow them to work with
> acceptable speed.
>
> Do you think that Buffers should be a part of classpath ? Or should they
> be left for jvm implementors ? There is quite a lot of code there - all
> kinds of wrapper classes, splitting, views etc. But on the other hand,
> core get/set functions have to be really optimized for specific jvm...

An implementation of the New I/O API belongs to both of JNI routines
and a class library (like Classpath). As Cedric Berger wrote to the
GCJ list, the API introduces 3 JNI functions, NewDirectByteBuffer,
GetDirectBufferAddress and GetDirectBufferCapacity.

The API set needs many native methods not only Java classes.
Who implements them depends on the cases.

If a JVM can support or accelerate the API some way, I'm very
interested in the techniques.

I interpreted the API spec as the followings and they may be clues:

 * The API implicitly allows us to do mmap(2).
   It can accelerate performance of I/O with files and devices
   in some cases.

 * The API implicitly allows us to do select(2).
   With it, a server program which provides services via network
   can serve a large number of clients without many threads
   corresponding to each client.

 * The API provides another I18N framework.


  Kazuyuki Shudo        address@hidden  http://www.shudo.net/