In the Before Times, the vast majority of software was written in garbage collected language where a working knowledge of the relative merits of C memory allocators is not useful or particularly relevant.
Why would the scads of people writing JavaScript, Java, python, go, rails, etc need to be aware of jemalloc?
>...the vast majority of software was written in garbage collected language
and even then recently it costed (us) quite a few months to blame JVM and later the default glibc memory allocator for running out native (not java heap memory) - had to exclude all possible native libs (zlib, zstd via jna), direct buffers, sockets, thread stacks and so on. Changing the malloc to jemalloc solved the issue, even though initially it was done for its debugging capabilities.
I'm never sure if I should be upset or happy when I've been debugging a problem for long enough that I finally decide to switch something out in order to improve visibility and that immediately solves the problem for entirely unexpected reasons. Particularly all the times when I couldn't readily discern why.
We changed to jemalloc first on a jvm service which we could never get to run in its kube memory limit. with jemalloc its been dead stable for years, and we made it the default for all jvm services
ZenoArrow · · focus · HN ↗
baq · · focus · HN ↗
stackghost · · focus · HN ↗
Why would the scads of people writing JavaScript, Java, python, go, rails, etc need to be aware of jemalloc?
xxs · · focus · HN ↗
and even then recently it costed (us) quite a few months to blame JVM and later the default glibc memory allocator for running out native (not java heap memory) - had to exclude all possible native libs (zlib, zstd via jna), direct buffers, sockets, thread stacks and so on. Changing the malloc to jemalloc solved the issue, even though initially it was done for its debugging capabilities.
It's just a great memory allocator.
fc417fc802 · · focus · HN ↗
javier2 · · focus · HN ↗