mapped io for non-default file system

[Remi Forax]

On 07/01/2013 10:03 AM, Philippe Marschall wrote:
> 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.

yes, Hotspot will use an inlining cache.
ByteBuffer get/put try to compete with C/C++ unsafe array access, so the 
overhead of such cache,
even if in the best case of the monomorphic inlining cache the overhead 
is just a pointer check against a constant,
this overhead is for that particular case just an unnecessary overhead.

>   Given the overhead of all the JNI methods in MappedByteBuffer I have my doubts.

These methods are not called often or exactly should not be called often.

>
> Cheers
> Philippe

cheers,
Rémi