notes on binding C++

[Maurizio Cimadamore]

Hi Samuel,
I'm not aware of any concrete C++ effort right now; as I mentioned to 
you the goal for now is to get native interop (C) up and running with a 
stable API - once that's done we can build more on it (and that means 
getting to C++).

Regarding your question of whether generating stubs is really going to 
buy us much compared to just use JNI as JavaCPP is doing, I take your 
point; if you generate an _opaque_ stub and then compile-it with the 
target compiler, you end up in the same performance ballpark as JavaCPP, 
I believe, as the invocation cannot be direct and the JIT can't probably 
see through the stub call.

But I've seen other plans on how to generate those stubs, and such plans 
include using JVM code snippets (for which there's a branch in the 
panama repo):

http://mail.openjdk.java.net/pipermail/panama-dev/2016-August/000506.html

A machine code snippet is a piece of assembly (hence platform dependent 
code) which can be packaged up and exposed to user as a method handle. 
This means that the JIT can optimize it more or less in the same way as 
it does for other method handles - meaning that it will now be able to 
see through the stub call and optimize that, if possible/needed. There 
are obviously a lot of 'ifs' in this story (the code snippet extension 
is experimental), but I think it should be clear that, at least on 
paper, it has the potential to be more efficient than simply generating 
some C/C++ stub, compiling it, and then calling it opaquely.

You can find some examples of code snippets in this test:

http://hg.openjdk.java.net/panama/dev/file/8437963c6282/test/jdk/panama/snippets/MachineCodeSnippetSamples.java#l51

Maurizio


On 30/01/18 08:45, Samuel Audet wrote:
> On 01/30/2018 02:14 PM, Henry Jen wrote:
>>
>>> On Jan 29, 2018, at 8:37 PM, Samuel Audet <samuel.audet at gmail.com> 
>>> wrote:
>>>
>>> BTW, if the C API of libclang exposes all the features we need, it 
>>> is already possible to use it from Java: 
>>> https://github.com/bytedeco/javacpp-presets/tree/master/llvm Is 
>>> jextract in a good enough shape to offer us such an interface to 
>>> work with and do some dogfooding? If so, it might also be a good 
>>> place to start a testbed for jextract too. That is exactly what the 
>>> JavaCPP Presets are: A testbed for JavaCPP. This is what makes 
>>> JavaCPP actually work with (a few) C++ libraries out there in the 
>>> wild--unlike SWIG, CppSharp, rust-bindgen, etc. Thoughts?
>>>
>>
>> We have achieved to run jextract on top of libclang binding generated 
>> by jextract awhile back, probably need to bring up-to-date with 
>> current updates.
>>
>> It’s the idea that after this bootstrapping process, we would like to 
>> be able open up other capability provided by libclang, also this 
>> dogfooding would server as a validation to our approach is working.
>>
>
> Ok, cool! Has anyone tried with the C++ API of Clang since then? Now 
> that sounds like awesome dogfooding to me. And if we can get that 
> wrapped, we're probably not going to have much of any issues with 
> other C++ libraries out there, and I will happily retire JavaCPP. :)
>
> Samuel