Cleanup a few more allocations in X.509 #69831
Conversation
ghost
added
the
|
Tagging subscribers to this area: @dotnet/area-system-security, @vcsjones Issue DetailsA few more small allocations that can be avoided, and a little bit of formatting cleanup in
|
| string keyAlgorithmOid = GetKeyAlgorithm(); | ||
| byte[] parameters = GetKeyAlgorithmParameters(); | ||
| byte[] keyValue = GetPublicKey(); | ||
| byte[] parameters = Pal.KeyAlgorithmParameters; |
There was a problem hiding this comment.
The public APIs GetKeyAlgorithmParameters and GetPublicKey create defensive copies, then we were feeding them in to AsnEncodedData, which again created defensive copies. If we go to the PAL directly for the bytes we can avoid the first defensive copy.
| private SafeCreateHandle PreparePoliciesArray(bool checkRevocation) | ||
| { | ||
| IntPtr[] policies = new IntPtr[checkRevocation ? 2 : 1]; | ||
| Span<IntPtr> policies = checkRevocation ? stackalloc IntPtr[2] : stackalloc IntPtr[1]; |
There was a problem hiding this comment.
It's okay to put stack data in to CFArrayCreate as long as the items themselves are not from the stack. It creates a CoreFoundation array from the contents of the stack, it doesn't try to take ownership of the stack data.
We're also doing this in SafeDeleteSslContext as well.
2 participants
A few more small allocations that can be avoided, and a little bit of formatting cleanup in
X509Certificate2.