notes on binding C++

[Samuel Audet]

Yes, performance improvement for C is the priority, and usability for 
C++ is secondary. But building "more on it" is not going to work in my 
opinion. It will require a redesign of pretty much everything anyway, so 
all efforts towards C++ will probably just be abandoned in the end. The 
message to the community needs to be clearer than that!

When I talk about "virtual inheritance", for example, I talk about 
"callbacks". So this isn't an issue related to only C++. For the sake of 
the argument, how are function pointers that call back into a Java 
method implemented with jextract? My impression is that they use JNI. If 
they do not, I would be curious to know how this is achieved!

Samuel

On 01/30/2018 06:33 PM, Maurizio Cimadamore wrote:
> 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
>