RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512 instructions [v9]

Volodymyr Paprotski duke at openjdk.org
Wed Nov 9 02:22:04 UTC 2022


On Wed, 9 Nov 2022 00:10:48 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix 32-bit build
>
> src/hotspot/share/opto/library_call.cpp line 7014:
> 
>> 7012:   const TypeKlassPtr* rklass = TypeKlassPtr::make(instklass_ImmutableElement);
>> 7013:   const TypeOopPtr* rtype = rklass->as_instance_type()->cast_to_ptr_type(TypePtr::NotNull);
>> 7014:   Node* rObj = new CheckCastPPNode(control(), rFace, rtype);
> 
> FTR it's an unsafe cast since it  doesn't involve a runtime check from `IntegerModuloP` to `ImmutableElement`. Please, lift as much checks into Java wrapper as possible.

Ah, yeah.. I quite suspected I didn't emulate all the bytecodes needed. Thanks for the info.

So this is a bit of a quandary.. I had done the intrinsic more in Java before, but it slows down the non-intrinsic path (This was the discussion we were having with Jamil).

In Java, the limbs are not 'accessible' per-se.. They are in a separate package hidden behind and interface.. and in a nested non-static class inside an abstract class... Its quite well designed. Its just makes what I want to do break most encapsulations.

There is a method (`asByteArray`) to extract the limbs that I was previously using, but that slows down non-intrinsic path (to be honest it slows down the intrinsic path too, but the assembler makes some of that back.. You can see that from the numbers I posted for Jamil, vs original in the PR header; originally I got 18x, and now with accessing limbs directly its 19x). 

If I had some way to check 'is intrinsic available', I could at least not slow down the current code. I would still have to break the encapsulation to do the checks/casts though. It all seems less-then-perfect.

-------------

PR: https://git.openjdk.org/jdk/pull/10582



More information about the security-dev mailing list