The post is itself a series of highlights from many of the contributing projects. A few of my favorites are from the sulong project:
A new API for accessing Java types and instantiating foreign objects from LLVM languages.
Use dynamic linker semantics when loading multiple bitcode files.
Support ELF files with embedded LLVM bitcode.
Pointers to bitcode functions can now be called from other languages
I haven't sat down to benchmarked anything but I'm curious if any of the overhead associated with JNI can be elided now that the JIT crosses that boundary. From my memory of Cliff Click's "Why is JNI Slow?"[0] much of the cost is copying data across the boundary, being conservative with GC'ing objects that could be used by native code, and being careful with registers and process state across the boundary.
From what I can tell, none of these apply anymore since graal/sulong compilers can "see" into the llvm bitcode and decide how careful it needs to be.
Comments
The post is itself a series of highlights from many of the contributing projects. A few of my favorites are from the sulong project:
A new API for accessing Java types and instantiating foreign objects from LLVM languages. Use dynamic linker semantics when loading multiple bitcode files. Support ELF files with embedded LLVM bitcode. Pointers to bitcode functions can now be called from other languages
I haven't sat down to benchmarked anything but I'm curious if any of the overhead associated with JNI can be elided now that the JIT crosses that boundary. From my memory of Cliff Click's "Why is JNI Slow?"[0] much of the cost is copying data across the boundary, being conservative with GC'ing objects that could be used by native code, and being careful with registers and process state across the boundary.
From what I can tell, none of these apply anymore since graal/sulong compilers can "see" into the llvm bitcode and decide how careful it needs to be.
Exciting times indeed.
[0]: https://www.youtube.com/watch?v=LoyBTqkSkZk