mapped io for non-default file system

Philippe Marschall philippe.marschall at
Mon Jul 1 08:54:23 PDT 2013

On Mon, Jul 1, 2013 at 3:36 PM, Remi Forax <forax at> wrote:
> On 07/01/2013 02:37 PM, Philippe Marschall wrote:
>> On Mon, Jul 1, 2013 at 11:45 AM, Remi Forax <forax at> wrote:
>>> On 07/01/2013 10:03 AM, Philippe Marschall wrote:
>>>> On Wed, Jun 26, 2013 at 8:49 PM, Remi Forax <forax at> 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.
>> Can you even measure that on a modern CPU? And that's assuming the
>> worst case when you actually have another implementation class loaded
>> and CHA does not kick in.
> get and put are basic primitives that are used every-where in IO code,
> so all the compiled codes dealing with IOs will need to be trashed if CHA/IC
> failed,
> this will create a giant deoptimization flood (not something pretty believe
> me).
>>>>    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.
>> Why do we care about their call overhead then?
> these methods => JNI methods.
> get/put are called very often in loops, force by example is not called very
> often.

But get/put are abstract in ByteBuffer and have two implementations,
one in HeapByteBuffer and one in DirectByteBuffer.

(sorry for OT)


More information about the nio-dev mailing list