notes on binding C++
Maurizio Cimadamore
maurizio.cimadamore at oracle.com
Sun Feb 4 21:10:45 UTC 2018
On 04/02/18 02:38, Samuel Audet wrote:
> The only thing that you have been able to show me until now requires
>
> Java -> C wrappers -> C++
>
> For C++ libraries, that gains us nothing over JNI! Except that now we
> have 2 ways of accessing native libraries that have very different
> APIs. Not so great for usability, but that is OK, in a way.
Going from Java to C wrappers is not the same of going from Java to JNI.
That's the whole point. The wrappers are Panama-friendly C-like entry
points, so we can jump straight from Java to the native wrapper entry
point w/o any overhead (if the foundations are laid well enough, that is).
Moreover, if we leave enough breadcrumbs around, the JIT might
understand that 'this is a wrapper around a C++ inlined function' (after
all there's only a limited amount of wrappers needed for C++ interop)
and optimize that suitably. This is an approach that is not too
dissimilar to what we have done with MethodHandles - where many
seemingly different method handles are implemented under the hood by an
handful of shared lambda forms, which the JIT knows how to optimize well.
So yes, there's still an hop before getting into C++, but the hop is not
a jump into an opaque world, as it currently is for JNI; and that's
where Panama extension to the VM/runtime can and should provide extra value.
Maurizio
More information about the panama-dev
mailing list