mapped io for non-default file system

[Philippe Marschall]

On Mon, Jul 1, 2013 at 11:45 AM, Remi Forax <forax at univ-mlv.fr> wrote:
> 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.

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.

>>   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?

Cheers
Philippe