[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-nio-dev
Subject:    Re: mapped io for non-default file system
From:       Philippe Marschall <philippe.marschall () gmail ! com>
Date:       2013-07-01 15:54:23
Message-ID: CA+LFMPjW11SGKAP_K3bsjwQ7wiLK3E+UdpReTYxtjWUXb5=0Ng () mail ! gmail ! com
[Download RAW message or body]

On Mon, Jul 1, 2013 at 3:36 PM, Remi Forax <forax@univ-mlv.fr> wrote:
> On 07/01/2013 02:37 PM, Philippe Marschall wrote:
>>
>> On Mon, Jul 1, 2013 at 11:45 AM, Remi Forax <forax@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@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.

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

(sorry for OT)

Cheers
Philippe
[prev in list] [next in list] [prev in thread] [next in thread]