MethodHandle for indirect/vtable call?

[Vladimir Ivanov]

 From JVM perspective, there's no major problem to represent an indirect 
call. (I even tried to optimize non-constant NEP case in MH.linkToNative 
prototype that way: represent it as an indirect call through NEP.target 
field.) But it requires changing/extending the interface between JVM and 
JDK. Right now, both call site "shape" (target function ABI) and target 
address are both tied to NativeEntryPoint and there's no way to make 
address non-constant without losing ability to inspect the ABI.
Untangling them should open the door for indirect call support.

One way to implement it would be to introduce a special kind of 
NativeEntryPoint which doesn't encapsulate an entry point, but accept 
one as a special parameter. Then JVM can use it to compute the actual 
address instead of loading a constant from NEP entry.

It doesn't address in any way the problem how to represent a virtual 
call in Foreign API.

Best regards,
Vladimir Ivanov

On 11.12.2020 18:38, Maurizio Cimadamore wrote:
> 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.