You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm wondering if there are any pitfalls or other considerations in trying to implement the same thing, but instead of UNSAFE.* family of functions -- using standard ByteBuffers? Seems like a straightforward change, but maybe I'm missing something.
Pros would be:
No dependency on sun.misc.* which prevents using modern JDK --release for modern versions (sun.misc is unavailable).
Potentially easier on AOT compilation.
In some sense it would be more "pure java".
Would support sliced heap byte buffers (with .arrayOffset > 0).
The code of course supports ByteBuffers, but only with zero arrayOffset, and internally it just uses them just as a byte[].
The text was updated successfully, but these errors were encountered:
It's mostly due to performance. It's currently hard (impossible?) to get the same performance as Unsafe when accessing ByteBuffers via their public APIs.
Once the Foreign Memory APIs (https://openjdk.org/jeps/393) stabilize and we update this library to a more recent version of the JDK, we may be able to rewrite it against those APIs.
Hi,
Thanks for the tool!
I'm wondering if there are any pitfalls or other considerations in trying to implement the same thing, but instead of UNSAFE.* family of functions -- using standard ByteBuffers? Seems like a straightforward change, but maybe I'm missing something.
Pros would be:
--release
for modern versions (sun.misc is unavailable).The code of course supports ByteBuffers, but only with zero arrayOffset, and internally it just uses them just as a byte[].
The text was updated successfully, but these errors were encountered: