RFC: Refactoring SystemABI

[Samuel Audet]

Thanks for sharing your thoughts!

So, can we expect the binder from Panama to converge in some way to what 
Graal Substrate VM is offering? They already recommend it over JNI:
https://github.com/oracle/graal/blob/master/substratevm/LIMITATIONS.md#java-native-interface-jni

Actually, I think that would be a great way to go about it. Basically, 
for AOT we know we can do what Substrate VM does, and for when JIT is 
available it could go the SystemABI route, but where the higher-level 
API and annotations are the same. Their API doesn't use a lot of 
generics though and I'm sure it would need to be tweaked, so your team 
and their team would need to come to an understanding. Is this something 
that sounds achievable?

Or are you saying that your teams cannot cooperate for whatever reason 
and Panama would have to basically replicate Substrate VM?

Samuel

On 12/04/2018 08:30 PM, Maurizio Cimadamore wrote:
> 
> On 04/12/2018 08:05, Samuel Audet wrote:
>> In any case, in general, from a high-level point of view, what can we 
>> expect from Panana and AOT? Will mobile applications that can't use a 
>> JIT compiler have to basically stick with JNI to get the highest 
>> performance for the foreseeable future? 
> 
> We have thought about this and I have been studying the Graal native 
> image Pointer API and annotations for a while and came out convinced 
> that there are enough similarities that it should be possible to 
> replicate whatever Graal AOT does for annotated native methods using 
> Panama annotations and API instead. The underlying concepts are very 
> similar.
> 
> In a way, it would be like running our 'binder' statically, so that 
> references to native symbols are resolved ahead of time, and calls to 
> Panama interface methods can be compiled down to direct native calls.
> 
> This should be possible on both Graal and Hotspot AOT support.
> 
> I can't share any details since there has been no concrete experiment in 
> this direction, but I do believe the ingredients are there, or similar 
> enough that some solution should be possible.
> 
> Another direction that we considered was to pre-bind Panama interfaces 
> at module link time. This is not AOT, strictly speaking, but static 
> bytecode spinning. This is another solution that can mitigate the cost 
> of the Panama machinery in contexts where startup cost is paramount (the 
> JDK itself is one of those cases).
> 
> Maurizio
>