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

[Xiaohong Gong]

Hi Vladimir, Paul,

Thanks for all the feedback!

> Patch Set 80:
> 
> >> 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).

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!


> > 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