Eclipse OpenJ9: A Java Virtual Machine for OpenJDK that's optimized for small footprint, fast start-up, and high throughput. Builds on Eclipse OMR (https://github.com/eclipse/omr) and combines with the Extensions for OpenJDK for OpenJ9 repo.
This issue is to track the optimization of unbacked ByteBuffer processing in GCM.
The issue originated in my discussion with @keithc-ca here. In Summary, ByteBuffers can be either backed or not backed by an array (indirect buffers vs direct buffers). Currently, the only way to send data from Java to OpenSSL (which is how GCM is currently implemented in OpenJ9) is by converting the ByteBuffer to a byte array. Hence, when a ByteBuffer is not backed by an array, a new array has to be allocated and the data is copied to it. This sacrifices performance.
JNI code can access the data in a direct buffer by using GetDirectBufferAddress (no copying required).
However, I believe there are more situations than just direct and array-backed buffers.
This issue is to track the optimization of unbacked ByteBuffer processing in GCM.
The issue originated in my discussion with @keithc-ca here. In Summary, ByteBuffers can be either backed or not backed by an array (indirect buffers vs direct buffers). Currently, the only way to send data from Java to OpenSSL (which is how GCM is currently implemented in OpenJ9) is by converting the ByteBuffer to a byte array. Hence, when a ByteBuffer is not backed by an array, a new array has to be allocated and the data is copied to it. This sacrifices performance.