MethodHandle for indirect/vtable call?

[Maurizio Cimadamore]

Hi Nikita,
I think I agree with your analysis. Jorn and I discussed a similar topic 
few months ago, and I agree the current linker API seems to be to 
focused on the idiomatic 90% case of regular downcall. This is 
inconvenient for at least 2 reasons - the first is the one you mention: 
if the target address keeps changing you can't really reuse the method 
handle. Secondly, it is very likely that, when extracting an entire API, 
we will find many functions which share the same signature - generating 
a fresh new MH for each seems a bit of an overkill.

That said, I believe that there might be implications on the intrinsics 
machinery in what you're asking - if I'm not wrong, the intrinsic 
machinery does really expect all the ingredient of a call (including the 
target address) to be _constant_ - otherwise it can imagine it could be 
hard to emit generic assembly for that(how is the address communicated 
to the assembly stub) ?

So, yes, this is an issue - and I think one that will be addressed (not 
in Java 16 though) - there's an open question as to how much fast we can 
make the general MH you describe - it might be possible that the linker 
API will have two flavors of "downcallHandle".

Cheers
Maurizio


On 11/12/2020 15:16, Nikita Nemkin wrote:
> Hi all,
>
> It seems that there's no native MethodHandle variant that takes a
> function pointer in addition to function arguments. I expected such
> method handles to be available for implementing indirect/vtable call
> sites. Without them, MethodHandles can't be cached statically per
> method (or per signature), since the target of each call could be
> different.
>
> Isn't static caching of method handles necessary for optimization?
> What's the best practice for indirect calls?
>
> This is important for wrapping Windows platform APIs, many of which
> are COM-based.