mapped io for non-default file system

[Philippe Marschall]

On Wed, Jun 26, 2013 at 8:49 PM, Remi Forax <forax at univ-mlv.fr> wrote:
> On 06/26/2013 08:12 PM, Philippe Marschall wrote:
>>
>> Hi
>>
>> Currently it's not possible for a non-default file system to provide
>> mapped io. A custom FileSystemProvider can override #newFileChannel
>> and return a custom FileChannel. This channel class has to implement
>> #map (since it's abstract in FileChannel) and return a
>> MappedByteBuffer. However even though MappedByteBuffer is abstract it
>> can not be implemented by custom file systems because the constructors
>> are package protected and it has final methods that call native
>> methods (and require a FileDescriptor).
>>
>> So my question is whether this is intentional because the semantics
>> are supposed to be mmap() or rather an oversight. If it's intentional
>> then maybe a comment on FileChannel#map would be helpful to document
>> the expected behaviour for non-defaulft file systems
>> (UnsupportedOperationException or IOException).
>
>
> I believe it's intentional, in order to avoid a dynamic dispatch
> (or at least some class checks) when doing a get or a put (which will be a
> real perf killer),
> all NIO buffers inherits from MappedByteBuffer and not the opposite.
> It's not pretty, but you can not let users to freely subclass
> MappedByteBuffer because of that.

Wut? I can't believe HotSpot is still that naïve, surely it must at
least use IC or PIC. Given the overhead of all the JNI methods in
MappedByteBuffer I have my doubts.

Cheers
Philippe