Repository navigation
Use PyMem_Raw* allocator for OpenSSL in _ssl and _hashlib #156228
Description
OpenSSL allows overriding its allocator with CRYPTO_set_mem_functions(), currently _ssl and _hashopenssl use the default system malloc. I am filing this issue to investigate if we can set it to PyMem_Raw* so that on free-threading it uses mimalloc which would scale better. Previously, there have been reports of high memory usage of ssl on glibc allocator, it would be worth checking if doing this fixes that as well.
Activity
kumaraditya303 commentedon Aug 23, 2026
I analyzed the effect of #156229 on the reproducer from #109534 with Claude. GIL build.
Two worktrees off the same commit, only difference is #156229.
gcc -O3 -DNDEBUG --with-mimalloc, glibc 2.39, OpenSSL 3.0.13. Reproducer from #109534 at 2500 concurrent connections x 4 waves. RSS measured after all connections close andgc.collect(), then again aftermalloc_trim(0). Baseline ~24 MB, average of 2 runs.malloc_trim(0)reclaimsPYTHONMALLOC=mimallocPYTHONMALLOC=mimallocWith the default allocator there is no effect, and there can't be:
PYRAW_ALLOCisMALLOC_ALLOCand_PyMem_RawMallocis a baremalloc(), so #156229 sends OpenSSL frommallocto a wrapper aroundmalloc. Same arena, same retention. The difference in the table is noise.With
PYTHONMALLOC=mimallocit works as intended — OpenSSL's allocations leave the glibc arena.malloc_trim(0)reclaims 133 MB on main and nothing with #156229, which puts OpenSSL's share under this load at 133 MB. Post-gc RSS goes from ~177 MB down to ~47 MB.gh-156228: Use PyMem_Raw allocators for OpenSSL in `_ssl` and `_hashl…
pythongh-156228: Use PyMem_Raw allocators for OpenSSL in `_ssl` and `…