bc-java icon indicating copy to clipboard operation
bc-java copied to clipboard

Performance Degradation with JDK 17, from JDK8

Open 4devwithgit opened this issue 9 months ago • 1 comments

BC version - 1.78.1

Current JDK ./java -version openjdk version "17.0.14" 2025-01-21 IBM Semeru Runtime Open Edition 17.0.14.0 (build 17.0.14+7) Eclipse OpenJ9 VM 17.0.14.0 (build openj9-0.49.0, JRE 17 Linux amd64-64-Bit Compressed References 20250121_961 (JIT enabled, AOT enabled) OpenJ9 - 3c3d179854 OMR - e49875871 JCL - cbbc8b94a62 based on jdk-17.0.14+7)

Previous JDK ./java -version java version "1.8.0_421" Java(TM) SE Runtime Environment (build 8.0.8.30 - pxa6480sr8fp30-20240801_01(SR8 FP30)) IBM J9 VM (build 2.9, JRE 1.8.0 Linux amd64-64-Bit Compressed References 20240703_73934 (JIT enabled, AOT enabled) OpenJ9 - 177ad469d4e OMR - e74814c IBM - 3c87141) JCL - 20240731_02 based on Oracle jdk8u421-b09

With the same Application code for decryption, we are seeing a performance degradation of 16%.

Application receives an encrypted file, and it decrypts it and verifies the digital signature. This is done with 20 threads running to transfer 50k documents of size 1872 bytes.

Any suggestions to improve the performance will be appreciated. We see JDK is the only difference between the two tests, so if anything can be tuned at the JDK level? or at the BC level?

Thanks

4devwithgit avatar Apr 02 '25 13:04 4devwithgit

No real idea on this one BC is a multi-release jar though so some of the classes in use will be different. I can't really think of anything at the moment which would make it slower though - it's things like SecureRandom, XDH and EdDSA which are different, and the changes largely relate to provide additional interface implementations reflecting what's available in later JVMs.

dghgit avatar Apr 03 '25 17:04 dghgit

Inactive

dghgit avatar Aug 11 '25 04:08 dghgit