mapped io for non-default file system

[Remi Forax]

On 07/01/2013 02:37 PM, Philippe Marschall wrote:
> 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.

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.

>
> Cheers
> Philippe

cheers,
Rémi