Hi, I agree with this proposal but how about creating a deprecation period? For example: We will deprecate jemalloc support in 22.0.0 release and announce it in the release announce. We'll drop support for jemalloc in 24.0.0 release.
Thanks, -- kou In <ia0pr12mb7649b140ab025f0a38a007a8c7...@ia0pr12mb7649.namprd12.prod.outlook.com> "[DISCUSS][C++] Removing jemalloc support" on Tue, 19 Aug 2025 19:22:55 +0000, Vyas Ramasubramani <vy...@nvidia.com.INVALID> wrote: > A few days ago I opened > https://github.com/apache/arrow/issues/47309<https://github.com/apache/arrow/issues/47309#issuecomment-3196114599> > where it was suggested that I bring this question to the mailing list: > Given that jemalloc development has > stopped<https://jasone.github.io/2025/06/12/jemalloc-postmortem/> and the > repo is archived<https://github.com/jemalloc/jemalloc> I wonder if Arrow > should consider removing that support as well. Arrow has already moved to > mimalloc as the default allocator, and there are a number of open issues that > link back to jemalloc issues (I was brought here from a comment on > #44342<https://github.com/apache/arrow/issues/44342>). It might help reduce > some noise on this repo's issue tracker to remove jemalloc support > altogether. I don't know if there is a desire to support any particular > system where jemalloc is still preferred, though. If so, then delaying > jemalloc support removal could make sense too. Just thought I'd raise the > issue. > If developers would prefer to keep jemalloc support in Arrow until someone > finds an intractable issue to resolve, that would be fine. I have seen enough > other jemalloc-related issues on the issue board to suggest that there are > sufficient edge cases to consider remove jemalloc as an option regardless, > though. Given that jemalloc is no longer the default in Arrow, I would not be > surprised to see bit rot in jemalloc support going unnoticed for multiple > releases, and it could be worth nipping that in the bud.
