Fwd: State of the Isthmus

[Samuel Audet]

I understand the part about building a foundation, but I still don't see 
how it will improve performance over JNI for inline functions, which are 
the ones that would benefit most from the reduced call overhead. So, 
instead of focusing on C++, let's focus on inline functions. Until I see 
that this new foundation can provide performance improvements over JNI 
for inline functions, I will remain skeptical about its usefulness in 
practice. Could you let me know when you have data showing the 
improvements or an explanation about the new method for inline native 
functions? I think that will help me appreciate a lot better what this 
is all about. Thanks!

Samuel

On 05/09/2018 02:29 AM, Maurizio Cimadamore wrote:
> Hi Samuel,
> yes, you mentioned that before :-)
> 
> This document represents a start, an attempt to capture where our 
> efforts will be devoted in the next few months - we believe that having 
> a clean Java vs. C interop story is a crucial building block, not only 
> to e.g. have ways (other than JNI) to provide integration between the 
> JDK and core system libraries, but also upon which more complex layers 
> (such as C++) can be built. So, this document reflects that 
> prioritization (which you and I have discussed with you in the past [1]).
> 
> [1] - 
> http://mail.openjdk.java.net/pipermail/panama-dev/2018-January/000931.html
> 
> Cheers
> Maurizio
> 
> 
> On 08/05/18 15:35, Samuel Audet wrote:
>> I know I'm repeating myself, but I'm still trying to drive the point 
>> home that it's too bad there is still pretty much nothing about C++...
>>
>> Samuel
>>
>> On 05/08/2018 09:20 PM, Maurizio Cimadamore wrote:
>>> FYI
>>>
>>> Maurizio
>>>
>>>
>>>
>>> -------- Forwarded Message --------
>>> Subject:     State of the Isthmus
>>> Date:     Tue, 8 May 2018 13:19:00 +0100
>>> From:     Maurizio Cimadamore <maurizio.cimadamore at oracle.com>
>>> To:     panama-spec-experts at openjdk.java.net
>>>
>>>
>>>
>>> Hi,
>>> I've posted a new document here:
>>>
>>> http://cr.openjdk.java.net/~mcimadamore/panama/panama-binder-v3.html
>>>
>>> This document attempts to capture the state of the Java vs. native
>>> interop in a single and centralized place, and is organized into 3
>>> sections: there's a small intro which is used to outline the reference
>>> architecture of our solution - e.g. a binder which take some native
>>> bundles, consisting of interfaces + metadata and turns them into
>>> concrete implementation, which can then be poked by user code wanting
>>> access to native features.
>>>
>>> Then there's a section covering layouts - first layout are presented as
>>> a pseudo API, then a language syntax will also be discussed, so that we
>>> will be able to associate layout description to interfaces using
>>> annotations. This section is relatively language agnostic (as layouts
>>> are language agnostic).
>>>
>>> The last section is about the problem of mapping C types to Java
>>> carriers; as such, we zoom into the problem of C interop. We outline
>>> some principles which should govern this mapping, and then walk through
>>> the various features of the C language, and try to find, for each of
>>> these, the best way to model it in Java.
>>>
>>> Even though the document bears my name, I'd like to point out that this
>>> work is the result of countless discussions among the members of the
>>> Panama team - I'd like to thank everybody who contributed to these
>>> discussion, either directly or indirectly.
>>>
>>> In the upcoming weeks, we will create a new branch in the Panama repo
>>> (initially a child of the 'nicl' branch) and start working on the
>>> branch, by implementing the concepts described in this document. This
>>> document will also be updated to reflect significant changes in the
>>> binder API - as such, I believe this document will be very useful for
>>> anybody wanting to write a tool targeting the Panama infrastructure.
>>>
>>> Cheers
>>> Maurizio
>>>
>>>
>>
>