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

121–130 of 250 posts

Re: Jemalloc Postmortem

#121

Post by LtdJorge »

senderista wrote: post #86
o11c wrote: post #52

Earlier quoted context omitted.

For a long time, one of the major problems with alternate allocators is that they would never return free memory back to the OS, just keep the dirty pages in the process. This did eventually change, but it remains a strong indicator of different priorities. There's also the fact that ... a lot of processes only ever have a single thread, or at most have a few background threads that do very little of interest. So all…

> Semi-related: one thing that most people never think about: it is exactly the same amount of work for the kernel to zero a page of memory (in preparation for a future mmap) as for a userland process to zero it out (for its own internal reuse) Possibly more work since the kernel can't use SIMD

Why is that? Doesn't Linux use SIMD for the crypto operations?

Re: Jemalloc Postmortem

#123

Post by b0a04gl »

kstrauser wrote: post #22

I’ve wondered about this before but never when around people who might know. From my outsider view, jemalloc looked like a strict improvement over glibc’s malloc, according to all the benchmarks I’d seen when the subject came up. So, why isn’t it the default allocator?

[dead]

Re: Jemalloc Postmortem

#124

Post by nh2 »

masklinn wrote: post #70
vlovich123 wrote: post #57

Earlier quoted context omitted.

That’s because sane allocators that aren’t glibc will return unused memory periodically to the OS while glibc prefers to permanently retain said memory.

glibc will return memory to the OS just fine, the problem is that its arena design is extremely prone to fragmentation, so you end up with a bunch of arenas which are almost but not quite empty and can't be released, but can’t really be used either. In fact, Jason himself (the author of jemalloc and TFA) posted an article on glibc malloc fragmentation 15 years ago: https://web.archive.org/web/20160417080412/http://ww…

glibc does NOT return memory to the OS just fine.

In my experience it delays it way too much, causing memory overuse and OOMs.

I have a Python program that allocates 100 GB for some work, free()s it, and then calls a subprocess that takes 100 GB as well. Because the memory use is serial, it should fit in 128 GB just fine. But it gets OOM-killed, because glibc does not turn the free() into an munmap() before the subprocess is launched, so it needs 200 GB total, with 100 GB sitting around pointlessly unused in the Python process.

This means if you use glibc, you have no idea how much memory your system will use and whether they will OOM-crash, even if your applications are carefully designed to avoid it.

Similar experience: https://news.ycombinator.com/item?id=24242571

I commented there 4 years ago the glibc settings MALLOC_MMAP_THRESHOLD_ and MALLOC_TRIM_THRESHOLD_ should fix that, but I was wrong: MALLOC_TRIM_THRESHOLD_ is apparently bugged and has no effect in some situations.

A bug I think might be involved: "free() doesn't honor M_TRIM_THRESHOLD" https://sourceware.org/bugzilla/show_bug.cgi?id=14827

Open since 13 years ago. This stuff doesn't seem to get fixed.

The fix in general is to use jemalloc with

    MALLOC_CONF="retain:false,muzzy_decay_ms:0,dirty_decay_ms:0"
which tells it to immediately munmap() at free().

So in jemalloc, the settings to control this behaviour seem to actually work, in contrast to glibc malloc.

(I'm happy to be proven wrong here, but so far no combination of settings seem to actually make glibc return memory as written in their docs.)

From this perspective, it is frightening to see the jemalloc repo being archived, because that was my way to make sure stuff doesn't OOM in production all the time.

Re: Jemalloc Postmortem

#125

Post by hyperpape »

zozbot234 wrote: post #122

[flagged]

The maintainers are probably all making personally reasonable choices that we should support.

But it’s still sad that there’s probably no world where someone will still focus on jemalloc with professional support from their employer. It means that an important piece of technology will not continue improving.

Forking is possible, but it doesn’t look like the kind of project that many people could fork and improve, it requires a lot of focus by people with specific domain knowledge.

Re: Jemalloc Postmortem

#126

Post by mort96 »

alextingle wrote: post #116
rfoo wrote: post #105

Earlier quoted context omitted.

> 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.

Eh, no. The quotes mean "this is not a dependency on a system library". Quotes can include relative to the files, or they can include things relative to directories specified with -I. The only thing they can't is include things relative to directories specified with -isystem and system include directories.

I would be surprised if I read some project's code where angle brackets are used to include headers from within the same project. I'm not surprised when quotes are used to include code from within the project but relative to the project's root.

Re: Jemalloc Postmortem

#127

Post by dazzawazza »

I've used jemalloc in every game engine I've written for years. It's just the thing to do. WAY faster on win32 than the default allocator. It's also nice to have the same allocator across all platforms.

I learned of it from it's integration in FreeBSD and never looked back.

jemalloc has help entertained a lot of people :)

Re: Jemalloc Postmortem

#128

Post by 7bit »

zozbot234 wrote: post #122

[flagged]

I don't understand why you don't understand that you can be sad about this.

Parent stated that he's sad the project is no longer maintained. That's a perfectly reasonable and human response. Parent does not have to defend having an emotion, even less provide objective truth for why he feels sad.

If you don't agree, fine. But I don't see why one would write a paragraph long statement, I validating someone's emotional response.

Re: Jemalloc Postmortem

#129

Post by vkazanov »

lloeki wrote: post #87
vkazanov wrote: post #85

Earlier quoted context omitted.

Huh? Bsd-style licenses are fully compatible with gpl. The problem is exactly this: Facebook becomes the upstream of a key part of your system. And Facebook can just walk away from the project. Like it did just now.

They are compatible but that's not the point. If it were included it would instantly become a LGPL hard-fork because of any subsequently added line of code, if not by "virality" of the glibc license, at least because any glibc author code addition would be LGPL, per GNU project policy/ideology. Also also this would he a hard bar to pass: https://sourceware.org/glibc/wiki/CopyrightFSForDisclaim As I recall this is wha…

What prevents apple from working with gpl-style licenses is strict hatred towards code that they can't use without opensourcing it. So this is what prevents them from contributing to gpl projects: the need to control access to code.

Llvm is OK for them from this point of view: upstream is open but they can maintain and distribute their proprietary fork.

Re: Jemalloc Postmortem

#130

Post by zozbot234 »

7bit wrote: post #128
zozbot234 wrote: post #122

[flagged]

I don't understand why you don't understand that you can be sad about this. Parent stated that he's sad the project is no longer maintained. That's a perfectly reasonable and human response. Parent does not have to defend having an emotion, even less provide objective truth for why he feels sad. If you don't agree, fine. But I don't see why one would write a paragraph long statement, I validating someone's emotional…

> That's a perfectly reasonable and human response.

It's hardly a reasonable response. By casually saying that it's "sad" when a maintainer gives up on a project, GP is also including a very real and heavy implication that this is somehow wrong on their part and that they should continue to shoulder that burden, as a demand from the community. This is a really unhealthy attitude and we should all do away with it. Instead, just acknowledge that the project is now there for the taking by anyone who may be interested. There's nothing "sad!" about this whatsoever, and we should not pretend that there is.

Post reply on HN