Many KNet operations can, or cannot, be impacted during JNI operations because data can, or cannot, be the copy of the data available in the JVM.

[masesdevelopers]

          Many KNet operations can, or cannot, be impacted during JNI operations because data can, or cannot, be the copy of the data available in the JVM. 

As stated in https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html JVM can decide to copy, or pin, data depending on its internal implementation.

The data transfer used in KNet is based on JNI and the results of some benchmarks seems impacted from the following hypothesis:

• JVM makes a copy of the data before send it to JNI and replace back the object data when JNI returns: so there are multiple copies of data during data exchange;
• JVM Garbage Collector: some JNI methods can impact the GC operations since, depending on JVM implementation, the GC can pin or copy array of primitive types.

Current benchmarks are based on byte array to reduce exogenous interference (like the implementation of the serializers) and in general KNet specific implementation (KNetConsumer, KNetProducer, KNet Streams SDK, etc) uses byte array.

Maybe a better data exchange can be obtained reducing the number of array copies done during execution. An issue will be opened to investigate on this possible evolution, meanwhile this issue is reopened.

Originally posted by @masesdevelopers in https://github.com/masesgroup/KNet/issues/53#issuecomment-1979330526

[masesdevelopers]

A possibility to reduce the memory copy at CLR-JVM boundary comes from the use of ByteBuffer and especially, if it is supported, from the allocateDirect method. allocateDirect creates a memory area generally used from off-heap operations. However to verify this opportunity an enhancement shall be done on JNet because ByteBuffer is managed in that project and shall be found a way to access the memory allocated from the JVM directly from the CLR.