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