[VectorAPI] Enhancement of floating-point math vector API implementation

[Xiaohong Gong]

Hi Vladimir,

> > Yes, it's really a good idea to lift the native library stub code from JVM as well as the new added wrapper code into JDK level. But it's still un-avoidable to add the platform special codes like unboxing the boxed vectors for interpreter/c1 and the relative vector calling convention support. I'm not familiar with MethodHandle and Foreign Linker API, can it do the different handling for different platforms? I will spend time looking at this part. Thanks!
> 
> So far, vector calling conventions are a thing only in C2 and I don't expect that to change anytime soon. The rest of the JVM has to go through wrappers/adapters in order to call into vector code.
> 
> What is really unavoidable on the JVM level is that there should be different entry points for different calling conventions present. Until JVM is able to spin adapters for boxed calling conventions automatically, JNI wrappers can be manually coded to fulfill the need.
> 
> I don't think it is the right time to teach JVM to spin adapters for vector calling conventions now. It's more appropriate to cover that as part of proper support in Foreign Linker API.
> 
> Any reason why native code (called through JNI) can't extract a vector value from an instance of Vector class (using JNI) and pass it into a vector subroutine using vector calling conventions?

I think the native code wrapper through JNI should be something like the different assembler code (LoadVector/StoreVector) on different architectures, like what the wrapper in JVM in current prototype, right? And that's the main problem to me. Besides the JVM stub routine, I've no idea about other ways. It's appreciated if you have better idea. 

Thanks,
Xiaohong

-----Original Message
From: Vladimir Ivanov <vladimir.x.ivanov at oracle.com> 
Sent: Tuesday, January 10, 2023 2:48 AM
To: Xiaohong Gong <Xiaohong.Gong at arm.com>; Paul Sandoz <paul.sandoz at oracle.com>
Cc: panama-dev at openjdk.java.net; nd <nd at arm.com>
Subject: Re: [VectorAPI] Enhancement of floating-point math vector API implementation


> Yes, it's really a good idea to lift the native library stub code from JVM as well as the new added wrapper code into JDK level. But it's still un-avoidable to add the platform special codes like unboxing the boxed vectors for interpreter/c1 and the relative vector calling convention support. I'm not familiar with MethodHandle and Foreign Linker API, can it do the different handling for different platforms? I will spend time looking at this part. Thanks!

So far, vector calling conventions are a thing only in C2 and I don't expect that to change anytime soon. The rest of the JVM has to go through wrappers/adapters in order to call into vector code.

What is really unavoidable on the JVM level is that there should be different entry points for different calling conventions present. Until JVM is able to spin adapters for boxed calling conventions automatically, JNI wrappers can be manually coded to fulfill the need.

I don't think it is the right time to teach JVM to spin adapters for vector calling conventions now. It's more appropriate to cover that as part of proper support in Foreign Linker API.

Any reason why native code (called through JNI) can't extract a vector value from an instance of Vector class (using JNI) and pass it into a vector subroutine using vector calling conventions?

Best regards,
Vladimir Ivanov

>>> In the end, Vector API implementation should just call method handles prepared by Foreign Linker API for native vector math routines from some native library (SVML, SLEEF, or something else). It can be hidden behind a service interface which returns a MethodHandle when requested particular math operation of particular shape.
> 
> If Foreign Linker API supports the vector calling convention and used by Vector API for such math operations, the corresponding vector intrinsics are not needed anymore. Does this mean the difference result issue from interpreter/c1 and c2 compiler will do not exist? And the fixing is not needed anymore? Thanks!
> 
> Best Regards,
> Xiaohong Gong
> 
> -----Original Message-----
> From: Vladimir Ivanov <vladimir.x.ivanov at oracle.com>
> Sent: Saturday, January 7, 2023 6:11 AM
> To: Paul Sandoz <paul.sandoz at oracle.com>
> Cc: Xiaohong Gong <Xiaohong.Gong at arm.com>; 
> panama-dev at openjdk.java.net; nd <nd at arm.com>
> Subject: Re: [VectorAPI] Enhancement of floating-point math vector API 
> implementation
> 
> 
>>> As an idea for an incremental improvement, consider lifting native library linkage code from JVM into JDK code and refactor corresponding intrinsics (require new ones I believe) to accept the specialized entry point address of the correspoding vectorized math routine (instead of the operation code). Then C2 could use the address to generate direct leaf call into the stub.
>>>
>>> That would allow to make JVM code library-agnostic and abstract away all the differences between SVML and SLEEF libraries (and, in the future, any other library added as a backing implementation).
>>>
>>> On JDK level multiple plug-in implementations could be supported and the final decision what implementation to use is performed at runtime depending on the presence of required libraries or user choice.
>>>
>>
>> Yes, users could plug in using service providers. We would need to be careful about potential abuses. Might need to be gated, perhaps by Panama’s command --enable-native-access flag.
> 
> Service provides look very promising.
> 
> IMO it's fine to forbid non-trusted providers initially (in other words, all supported providers should be bundled with the JDK).
> 
> In the end, Vector API implementation should just call method handles prepared by Foreign Linker API for native vector math routines from some native library (SVML, SLEEF, or something else). It can be hidden behind a service interface which returns a MethodHandle when requested particular math operation of particular shape.
> 
> Best regards,
> Vladimir Ivanov