sun.misc.Unsafe is no longer available in JDK11 about slice HOT 5 CLOSED

I believe Unsafe is still available in the jdk.unsupported module. When we decide to migrate Java 11, I'd like to take a long look at using Varhandles, but I'm not sure it is possible to get the same performance as we have with Slice. Slice is fast because there is a single implementation (no virtualization), and it is not branchy. We use a single pice of code to access data in byte[] as we use for long[], but it appears that in the Varhandles API you have to have different handles to deal with each array type, and that would mean multiple implementations or branching. For the immediate future, we will continue with Unsafe, and will investigate Varhandles further.

from slice.

@Praveen2112 that comment seems more target at the Presto project. Slice is only about fast, safe, easy access to on/off heap memory. That said, the comment about LLVM assumes that LLVM is a better assembler than the assemblers in Java (Hotspot, J9, Graal), and then if you really want LLVM, you can just use the Azul Zing JVM. At then end of the day, if you are getting 2x better performance, I suggest you try tuning your implementation instead of switching languages (BTW, if you want to verify the JVM assembly there is a plugin that will dump it for specific methods).

from slice.

At least Unsafe still remains in OpenJDK11 source code
http://hg.openjdk.java.net/jdk/jdk11/file/6889f13694c6/src/jdk.unsupported/share/classes/sun/misc/Unsafe.java

It seems only Unsafe.defineClass is deprecated so far, which is not used in Slice.
So this might not be an issue for now.

from slice.

Yeah. Sorry about my confusion.

Apparently JDK team are working toward deprecating sun.misc.Unsafe, but this will be step-by-step as they provide workarounds before totally deprecating Unsafe.

At least during JDK11, raw-memory access methods of Unsafe are available.

from slice.

I have a small doubt here. Is Slice and apache/Arrow are same ? Because both of them use Unsafe to store the data. Their representation of data in the byte[] is almost same , the only difference is arrow uses bit-map to store the null position when compared with FixedWidthBlock (which is removed from presto code) which stores the null position as a byte. If apache/Arrow can claim that it can communicate with other languages with no copying or serialization/de-serialization can it not be performed in Slice ? There is a library called Gandiva (https://github.com/dremio/gandiva) which provides a way to off load the filter and project operation to C (code generation using LLVM) for better performance. I ran some benchmarks comparing the Presto implementation (code generated filter and project operation) with that of gandiva (input provided as apache/Arrow format) and we got some 1.5-2x performance for filter and project operations. Can a similar logic be implemented for Presto ? @dain

from slice.