notes on binding C++
Henry Jen
henry.jen at oracle.com
Thu Feb 8 05:32:40 UTC 2018
> On Feb 7, 2018, at 7:44 PM, Samuel Audet <samuel.audet at gmail.com> wrote:
>
> On 02/06/2018 08:19 PM, Maurizio Cimadamore wrote:
>> On 06/02/18 07:52, Samuel Audet wrote:
>>> That sounds great and all, but it has been almost 4 years now, and the only feedback I am getting is that it does not yet support function-like macros, inline functions, C++ templates, etc. Ok, then, when? Why is a "limited amount of wrappers" taking so long?
>> Hi Samuel,
>> I think I've already responded to similar questions many times now, and I feel we're just going in circles; I sense your frustration, but unfortunately I do not have anything more to add to this discussion. I've told you what the focus is short/medium term (C interop), and what is the _rough_ plan after that. If that is not sufficient, or if you feel that we just got all the priorities wrong, or if you think we're just too slow, I'm sorry, but I don't think those kinds of concerns are of the kind that can be positively addressed over an email exchange.
>
> I am sorry, I think that came out the wrong way. What I was trying to say is that supporting C++ and making it as super efficient as you want it to be is a *very hard problem*, and you will require assistance from a lot of people--from outside Oracle--to pull this off. I am trying to make you realize that, and yes I am frustrated that I am unable to communicate this, even after almost 4 years...
>
> To make this conversation constructive, though, I am also trying to make suggestions, such as, why not use Clang? What is wrong with Clang? You already use it for jextract, and Graal already supports LLVM. Plus, people from Oracle Labs have already started work in this direction:
> Bringing Low-Level Languages to the JVM: Efficient Execution of LLVM IR on Truffle (see "4. Native Calls and Memory Management")
> http://ssw.jku.at/General/Staff/ManuelRigger/VMIL16.pdf
> Is something like this going to be integrated into Panama?
>
To be honest I don’t know how to answer this question, as I am not sure what you suggest we use Clang for. Like you said, we are using libclang in jextract to parsing header file, the usage limited to traverse AST to create corresponding Java APIs.
Panama is aimed to enable use of native libraries in binary form, use Clang backend and commit to Clang ABI(no standard for C++) is probably not practical?
As Maurizio pointed out before, jextract is a tool, and there can be different tools for different purpose. We are simply not there yet to explore other things, but we want to enable the community to experiment on top of what panama runtime can offer. Thus the focus is to lay out the foundation.
> Another constructive comment I would like to make is, would it be possible to release all the relevant documents about jextract and Panama so that people outside of Oracle could participate and make this a community effort?
All code for jextract and runtime support are published in the repo, but unfortunately not much documentation as everything is prototyped in the code. The only effort I formalized into a document is for Type Descriptor spec, which you can find here[1], you probably noted that Maurizio is formulating a proposal to evolve this.
http://cr.openjdk.java.net/~henryjen/panama/doc/TypeDescriptor.html
> If you need more data to convince managers that this is required in order for this project to succeed, I can help with that! However, as I mentioned previously, I feel that my help (or the help from any outsiders for that matter) is not welcome here. It would be great if this state of affairs could be improved! (This might be for you, Bernard?)
>
I am sorry to hear that you feel this way, but this is not true. Feedbacks and help are always welcome, we probably didn’t do a very good job to communicate or respond, but I don’t recall many interactions here on mailing list until lately.
Cheers,
Henry
More information about the panama-dev
mailing list