From: Artur Biesiadowski <[EMAIL PROTECTED]> > 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 [EMAIL PROTECTED] http://www.shudo.net/ _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
