[foreign] some JMH benchmarks

[Maurizio Cimadamore]

On 14/09/18 19:04, Maurizio Cimadamore wrote:
>> I have a suggestion to bypass having to write out all the 
>> permutations though. What if, on the Java side, whenever there is a 
>> method that has a shape that can be optimized in this way (which is 
>> ABI dependent), spin and load a class which defines a single static 
>> native method with the needed signature, and annotate it. Then, in 
>> NativeLookup::lookup, detect this annotation, and instead of trying 
>> to look up the symbol in a loaded library generate a forwarding stub 
>> and link the native method to that instead. Then you can take a 
>> MethodHandle to the native method in the anonymous class and use that 
>> in the backing implementation.
> This is a good suggestion, although for now I'd like to keep things 
> simple. In principle I agree, with some spinning (and some VM fixup) 
> we could be able to get there. You also need to spin upcalls entry 
> points too :-)
thinking more about this, I'm not sure you can go all the way there. 
Yes, we could save the Java entry points - but somewhere, you still will 
need to define the native entry point (one for each shape). So, overall, 
I think what I have is a pragmatic (and honest) approach - where there's 
equal replication on the Java and native side. Spinning classes will 
help with Java replication but not much with the native one.

The good thing is that this problem has already been solved: the 
linkToNative machinery generates a 'native method handle' out of thin 
air with a given shape and target address. With machinery like that, 
then you can really get rid of hand-written entry points on either side 
of the FFI fence. Everything else is, in a way, a workaround.

Maurizio