RFC: Refactoring SystemABI

[Maurizio Cimadamore]

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