Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Jemalloc Postmortem

jasone.github.io

Post reply on HN
Print view View original

111–120 of 250 posts

Re: Jemalloc Postmortem

#111

Post by tecleandor »

thewisenerd wrote: post #94
adityapatadia wrote: post #84

Jason, here is a story about how much your work impacts us. We run a decently sized company that processes hundreds of millions of images/videos per day. When we first started about 5 years ago, we spent countless hours debugging issues related to memory fragmentation. One fine day, we discovered Jemalloc and put it in our service, which was causing a lot of memory fragmentation. We did not think that those 2 lines o…

indeed! most image processing golang services suggest/use jemalloc the top 3 from https://github.com/topics/resize-images (as of 2025-06-13) imaginary: https://github.com/h2non/imaginary/blob/1d4e251cfcd58ea66f83... imgproxy: https://web.archive.org/web/20210412004544/https://docs.imgp... (linked from a discussion in the imaginary repo) imagor: https://github.com/cshum/imagor/blob/f6673fa6656ee8ef17728f2...

Yep, imgproxy seems to use libvips, that recommends jemalloc. I was checking and this is a funny (not) bug report:

https://github.com/libvips/libvips/discussions/3019

Re: Jemalloc Postmortem

#113

Post by fc417fc802 »

mort96 wrote: post #98
Svetlitski wrote: post #45

Earlier quoted context omitted.

It’s just a huge pain to build and link against. Before the bazel 7.4.0 change your options were basically: 1. Use it as a dynamically linked library. This is not great because you’re taking at a minimum the performance hit of going through the PLT for every call. The forfeited performance is even larger if you compare against statically linking with LTO (i.e. so that you can inline calls to malloc, get the benefit o…

Everything from Google is an absolute pain to work with unless you're in Google using their systems, FWIW. Anything from the Chromium project is deeply intangled with everything else from the Chromium project as part of one gigantic Chromium source tree with all dependencies and toolchains vendored. They do not care about ABI what so ever, to the point that a lot of Google libraries change their public ABI based on w…

Reading this perspective was interesting. I can appreciate that things didn't fit into your workflow very well, but my experience has been the opposite. Their projects seem to be structured from the perspective of building literally everything from source on the spot. That matches my mindset - I choose to build from scratch in a network isolated environment. As a result google repos are some of the few that I can count on to be fairly easy to get up and running. An alarming number of projects apparently haven't been tested under such conditions and I'm forced to spend hours patching up cmake scripts. (Even worse are the projects that require 'npm install' as part of the build process. Absurdity.)

> Oh and you probably don't want multiple versions of a library in your binary, so be prepared to use Google's (probably outdated) version of whatever libraries they vendor.

This is the only complaint I can relate to. Sometimes they lag on rolling dependencies forward. Not so infrequently there are minor (or not so minor) issues when I try to do so myself and I don't want to waste time patching my dependencies up so I get stuck for a while until they get around to it. That said, usually rolling forward works without issue.

> if you try to build their libraries from source, that involves downloading tens of gigabytes of sysroots and toolchains and vendored dependencies.

Out of curiosity which project did you run into this with? That said, isn't the only alternative for them moving to something like nix? Otherwise how do you tightly specify the build environment?

Re: Jemalloc Postmortem

#114

Post by fc417fc802 »

einpoklum wrote: post #99
Svetlitski wrote: post #36

I understand the decision to archive the upstream repo; as of when I left Meta, we (i.e. the Jemalloc team) weren’t really in a great place to respond to all the random GitHub issues people would file (my favorite was the time someone filed an issue because our test suite didn’t pass on Itanium lol). Still, it makes me sad to see. Jemalloc is still IMO the best-performing general-purpose malloc implementation that’s…

> TCMalloc is great, but is an absolute nightmare to use if you’re not using bazel custom-malloc-newbie question: Why is the choice of build system (generator) significant when evaluating the usability of a library?

Because you need to build it to use it, and you likely already have significant build related infrastructure, and you are going to need to integrate any new dependencies into that. I'm increasingly convinced that the various build systems are elaborate and wildly successful ploys intended only to sap developer time and energy.

Re: Jemalloc Postmortem

#115

Post by LtdJorge »

ahartmetz wrote: post #104
mort96 wrote: post #98

Earlier quoted context omitted.

Everything from Google is an absolute pain to work with unless you're in Google using their systems, FWIW. Anything from the Chromium project is deeply intangled with everything else from the Chromium project as part of one gigantic Chromium source tree with all dependencies and toolchains vendored. They do not care about ABI what so ever, to the point that a lot of Google libraries change their public ABI based on w…

I think your rant isn't long enough to include everything relevant ;) The Blink web engine (which I sometimes compile for qtwebengine) takes a really long time to compile, several times longer than Gecko according to some info I found online. Google has a policy of not using forward declarations, including everything instead. That's a pretty big WTF for anyone who has ever optimized build time. Google probably just t…

Even with Firefox using Rust and requiring a build of many crates, qtwebengine takes more time. It was so bad that I had to remove packaged from my system (Gentoo) that were pulling qtwebengine.

And I build all Rust crates (including rustc) with -O3, same as C/C++.

Re: Jemalloc Postmortem

#116

Post by alextingle »

rfoo wrote: post #105
mort96 wrote: post #98

Earlier quoted context omitted.

Everything from Google is an absolute pain to work with unless you're in Google using their systems, FWIW. Anything from the Chromium project is deeply intangled with everything else from the Chromium project as part of one gigantic Chromium source tree with all dependencies and toolchains vendored. They do not care about ABI what so ever, to the point that a lot of Google libraries change their public ABI based on w…

> they make no effort what so ever to distinguish between public header files and their source code They did, in a different way. The world is used to distinguish by convention, putting them in different directory hierarchy (src/, include/). google3 depends on the build system to do so, "which header file is public" is documented in BUILD files. You are then required to use their build system to grasp the difference…

>> `#include "base/pc.h"`, where that `"base/pc.h"` path is not relative to the file doing the include.

> I have to disagree on this one.

The double-quotes literally mean "this dependency is relative to the current file". If you want to depend on a -I, then signal that by using angle brackets.

Re: Jemalloc Postmortem

#117

Post by the_mitsuhiko »

All the allocators have the same issue. They largely work against a shared set of allocation APIs. Many of their users mostly engage via malloc and free.

So the flow is like this: user has an allocation looking issue. Picks up $allocator. If they have an $allocator type problem then they keep using it, otherwise they use something else.

There are tons of users if these allocators but many rarely engage with the developers. Many wouldn’t even notice improvements or regressions on upgrades because after the initial choice they stop looking.

I’m not sure how to fix that, but this is not healthy for such projects.

Re: Jemalloc Postmortem

#120

Post by nicoburns »

jdsully wrote: post #66
vlovich123 wrote: post #60

Earlier quoted context omitted.

The “system” allocator is managing memory within a process boundary. The kernel is responsible for managing it across processes. Claiming that a user space allocator is greedily inefficient is voodoo reasoning that suggests the person making the claim has a poor grasp of architecture.

The "greedy" part is likely not releasing pages back to the OS in a timely manner.

That seems odd though, seeing as this is one of the main criticisms of glibc's allocator.
Post reply on HN