[infinispan-dev] Performance of accessing off-heap buffers: NIO & Unsafe

[Sanne Grinovero]

On 20 January 2014 14:23, Tristan Tarrant <ttarrant at redhat.com> wrote:
> Hi Sanne,
>
> ultimately I believe that it is not about the "intrinsic" (sorry for
> overloading the term) performance of the memory allocation invocations,
> but the advantage of using ByteBuffers as the de-facto standard for
> passing data around between Infinispan, JGroups and any I/O layers
> (network, disk). Removing various points of copying, marshalling, etc is
> the real win.

Absolutely. Still there was some skepticism from others building on
the amount of times we' d need to do some random access to these
buffers; my point is that it's probably an unfounded concern, and I
wouldn't like to have such theories to prevent evolution in this
direction.

Sanne

>
> Tristan
>
> On 01/20/2014 03:01 PM, Sanne Grinovero wrote:
>> At our meeting last week, there was a debate about the fact that the
>> (various) off-heap buffer usage proposals, including NIO2 reads, would
>> potentially be slower because of it potentially needing more "native"
>> invocations.
>>
>> At the following link you can see the full list of methods which will
>> actually be optimised using "intrinsics" i.e. being replaced by the
>> compiler as it was a macro with highly optimized ad-hoc code which
>> might be platform dependant (or in other words, which will be able to
>> take best advantage of the capabilities of the executing platform):
>>
>> http://hg.openjdk.java.net/jdk8/awt/hotspot/file/d61761bf3050/src/share/vm/classfile/vmSymbols.hpp
>>
>> In particular, note the "do_intrinsic" qualifier marking all uses of
>> Unsafe and the NIO Buffer.
>>
>> Hope you'll all agree now that further arguing about any of this will
>> be dismissed unless we want to talk about measurements :-)
>>
>> Kudos to all scepticals (always good), still let's not dismiss the
>> large work needed for this yet, nor let us revert from the rightful
>> path until we know we've tried it to the end: I do not expect to see
>> incremental performance improvements while we make progress, it might
>> even slow down until we get to the larger rewards.
>>
>> Cheers,
>> Sanne
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev