Re: RFR: 8346094: Harden X509CertImpl.getExtensionValue for NPE cases [v3]
On Sun, 16 Feb 2025 06:31:50 GMT, Konanki Sreenath wrote: >> Earlier code will trigger NPE if the certificate does not contain the >> extensions or if the requested extensions does not exist. The better >> approach for hardening **getExtensionValue** here is to to check for NULL >> explicitly before calling **getExtensionValue()** and avoding try-catch >> block which ensures the readability and maintainability. >> >> After scanning in multiple places where invokng getExtensions on the >> X509CertInfo reference, the check for NULL is added in the **getKeyUsage()** >> as well while calling before **getExtensionValue()** >> >> The associated tests are written and added in test class >> **CertificateExtensions**. Which will ensure to validate the >> **getExtensionValue()** and **getKeyUsage()** methods in **X509CertImpl** >> class. > > Konanki Sreenath has updated the pull request incrementally with one > additional commit since the last revision: > > JDK-8346094 : Harden X509CertImpl.getExtensionValue for NPE cases test/jdk/sun/security/x509/X509CertImpl/CertificateExtensions.java line 1: > 1: /* Another test `V3Certificate` in the same directory references the internal `CertificateExtensions` class by its simple name. There is a conflict with this new test and it does not compile. Consider renaming your new test. Thanks. - PR Review Comment: https://git.openjdk.org/jdk/pull/23315#discussion_r1957341274
Re: RFR: 8347606: Optimize Java implementation of ML-DSA
On Fri, 14 Feb 2025 17:11:16 GMT, Bernd wrote: >> It turns out that initializing a multidimensional array with `int[][] a = >> new int[rows][cols]` is slower than allocating each column in a loop. Since >> we do a lot of large multidimensional array allocations in ML-DSA, the >> optimized initialization improves performance by roughly 10%. > > src/java.base/share/classes/sun/security/provider/ML_DSA.java line 1237: > >> 1235: return res; >> 1236: } >> 1237: > > Centralizing the allocation into a helper on its own Looks unseful (for > resource Management, debugging/profiling and to pick the optimal > implementation). > > but it’s a shame that 2 dimensional allocations are sub-optimal, shouldnt > that be addressed in the jvm (or c2?) Indeed, it's better if hotspot can recognize and optimize the bytecode sequence generated by javac, or javac should generate bytecode like these methods to speed up allocation in general. Is splitting the allocation into a dedicated method a factor? I know this may affect JIT compilation heuristics. - PR Review Comment: https://git.openjdk.org/jdk/pull/23642#discussion_r1957355167
