reusing more of LLVM

Sun Feb 3 21:27:32 UTC 2019

On 03/02/2019 03:47, Samuel Audet wrote:
> Hi, Vladimir, Maurizio,
>
> Thanks for taking the time to explain a few things. I was not 
> referring to the Java side API at all. We obviously need some way to 
> use all that from Java, that's fine, but the implementation needs 
> something to actually function. Right now, as Maurizio points out, 
> it's relying on MethodHandle, but unless we find a way to make it 
> efficient with AOT compilers for Android or Substrate VM, the API has 
> to be able to support something else anyway. It could be LLVM, which 
> works just as well in either AOT or JIT mode, but why is this out of 
> scope for Panama?

>
> After reading your replies, one reason that comes to my mind is to not 
> bring another JIT compiler to the mix. In other words, we want to 
> reuse C2 or Graal. That's a fine goal, but it should be stated as such 
> somewhere.
>
> Moreover, it appears that it's not typically possible to express all 
> of an ABI with only LLVM IR; we need Clang:
> https://stackoverflow.com/questions/25127874/c-abi-with-llvm
> Apparently in contradiction to what Vladimir says, that tells me it's 
> going to be a lot of work to support all possible C functions with 
> something like SystemABI, or am I wrong?

In LLVM, you need to rely on Clang to 'lower' certain details of 
SystemABI in a way that LLVM can digest. That's true in Panama as well - 
that's why we have layout, descriptors and such: to capture information 
that is relevant in order to perform a call accoriding to a given API. 
Usually, a SystemABI classifies arguments by kind (e.g. struct, floating 
point or integral), size (8, 32, ...) etc. Once you have an unambiguous 
about these things, if you know your target ABI, there's always a way to 
go from a description of the call in terms of (arguments, layouts, Java 
carriers) to an actual native call.

Maurizio

>
> In any case, I understand now why LLVM as a JIT isn't part of the 
> solution, but it took me a while to put all the pieces together. This 
> is the kind of information that I wish could be cataloged somewhere. 
> That way, people like me wouldn't need to spend so much time searching 
> from various unrelated sources. I hope others looking for the reasons 
> behind these decisions will find this thread, at least.
>
> BTW, I think I've finally understood what I would be happy with, but 
> it's unrelated to LLVM, so I'll start a new thread about that!
>
> Samuel
>
> On 2/2/19 6:17 AM, Maurizio Cimadamore wrote:
>>
>> On 01/02/2019 19:49, Vladimir Ivanov wrote:
>>>
>>>> Thanks for taking the time to reply. I'm talking about SystemABI, 
>>>> in this case. Maurizio posted a demo of how to call functions like 
>>>> getpid(), pow(), qsort() here previously:
>>>> https://mail.openjdk.java.net/pipermail/panama-dev/2018-November/003316.html 
>>>>
>>>>
>>>> LLVM has all the machinery to JIT compile all that in the same way, 
>>>> and already includes ABIs for many architectures, see this tutorial 
>>>> for example where they wrap the API in a toy language:
>>>> http://llvm.org/docs/tutorial/LangImpl04.html#adding-a-jit-compiler
>>>>
>>>> So, why not reuse that code? I would really like to understand the 
>>>> reasons why this wasn't considered. Is it because it's a C++ API? 
>>>> But isn't that the goal of Panama Foreign/Native anyway? To let 
>>>> Java developers use C++ APIs? If there are technical reasons why 
>>>> this wouldn't work, I honestly can't think of anything.
>>>
>>> Sorry, I still don't fully understand your question. You start with 
>>> System ABI API and then jump to "LLVM as a JIT", but I consider 
>>> those as completely orthogonal (API vs implementation considerations).
>>
>> Right - SystemABI, at least the one discussed in the the thread you 
>> mention, is just a Java API to get a MethodHandle given a native 
>> function. MethodHandle is the API toolkit that allows low level 
>> frameworks to speak about things that can be invoked (not necessarily 
>> Java methods) - it is a valuable tools in many context and, since its 
>> inception with JSR 292 it has changed the landscape when it comes to 
>> allow foreign languages to be implemented on top of the VM (many 
>> existing interpreters  for scripting languages, such as JRuby and 
>> Jython have in fact been rewritten to take advantages of these 
>> features).
>>
>> So, what Panama's SystemABI does here is to simply close an hole: you 
>> can currently ask a MethodHandle for a Java method, or a MethodHandle 
>> for a native, JNI method. But there's no way to ask for MethodHandle 
>> that simply acts as an entry point to directly call an underlying 
>> native function (e.g. a MethodHandle which describes a call to 
>> 'getpid') - or the opposite: to turn an existing method handle into a 
>> pointer which can be passed to native code as a callback.
>>
>> I don't see how this can be described as re-inventing LLVM - to me it 
>> seems like making the JSR 292 machinery aware of the new capabilities 
>> offered by the layers of integration provided by the Panama API.
>>
>> Maurizio
>>
>>>
>>> I'd like to reiterate that "LLVM as a JIT" discussion is out of 
>>> scope for Project Panama. Moreover, it's completely unrelated to API 
>>> considerations which should be implementation-agnostic: it doesn't 
>>> matter what the JVM relies on under-the-hood - C2, Graal, 
>>> Terracotta, LLVM - when it comes to API.
>>>
>>> From compiler framework (whichever you prefer more) perspective, ABI 
>>> support is a simple task (even not worth calling it a problem).
>>> The real challenges come when you try to mix code of different 
>>> origins (e.g., managed vs unmanaged) and want to minimize the 
>>> overhead of interactions while preserving correctness.
>>>
>>> On API level it pushes for a flexible API to communicate important 
>>> semantics both ways and to compiler, so it has enough information to 
>>> keep the boundary as thin as possible.
>>>
>>> That's why I'm confused when you refer to both System ABI *API* and 
>>> LLVM *compiler framework*.
>>>
>>> But if you are mostly concerned with implementation side, then I 
>>> don't see LLVM as a viable option (as of now), because there's no 
>>> production-ready LLVM-based compiler available in OpenJDK to rely on.
>>>
>>> Best regards,
>>> Vladimir Ivanov
>>>
>>>> On 2/1/19 9:17 AM, Vladimir Ivanov wrote:
>>>>> Samuel,
>>>>>
>>>>> Can you elaborate your point a bit, please?
>>>>>
>>>>> Shark was an attempt to bring LLVM-based JIT compiler to HotSpot 
>>>>> JVM, but that goal is orthogonal to Panama where the focus is on 
>>>>> interconnecting managed code with native code / hardware.
>>>>>
>>>>> LLVM definitely looks attractive in some respects, but I don't 
>>>>> understand what you mean by "reimplementing portions of LLVM in 
>>>>> Java".
>>>>>
>>>>> Best regards,
>>>>> Vladimir Ivanov
>>>>>
>>>>> On 31/01/2019 14:40, Samuel Audet wrote:
>>>>>> I am starting the get the impression that Panama is basically 
>>>>>> reimplementing portions of LLVM in Java as part of SystemABI. How 
>>>>>> much effort would it take to, for example, implement the required 
>>>>>> subset of the Java ABI in LLVM? Doing it that way, we would not 
>>>>>> need to test the C/C++ ABI, at least, making it possible instead 
>>>>>> to reuse tests from the JDK itself, or am I talking nonsense 
>>>>>> here? Looks like that might be challenging as well: 
>>>>>> http://openjdk.java.net/jeps/8189173. In any case, it would be 
>>>>>> great if we could have a discussion about these things instead of 
>>>>>> having OpenJDK dictate everything!
>>>>
>