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

171–180 of 250 posts

Re: Jemalloc Postmortem

#171

Post by zozbot234 »

pvg wrote: post #168
zozbot234 wrote: post #130

Earlier quoted context omitted.

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

You don't really get to decide whether someone's entirely in-passing mention of an emotional response to developments in something they worked on is 'reasonable' or not, and more importantly, it's not at all a topic of interesting conversation, just pedantic nitpicking.

[flagged]

Re: Jemalloc Postmortem

#172

Post by pvg »

zozbot234 wrote: post #171
pvg wrote: post #168

Earlier quoted context omitted.

You don't really get to decide whether someone's entirely in-passing mention of an emotional response to developments in something they worked on is 'reasonable' or not, and more importantly, it's not at all a topic of interesting conversation, just pedantic nitpicking.

[flagged]

Project participants showing up to HN to discuss their work is one of the more interesting and valuable things we have here and a 'community norm' in which they start getting hectored over tiny details or pet issues unrelated to the work would not be a good one - it just drives people away.

Re: Jemalloc Postmortem

#173

Post by xcrjm »

klabb3 wrote: post #147
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…

> we (i.e. the Jemalloc team) weren’t really in a great place to respond to all the random GitHub issues people would file Why not? I mean this is complete drive-by comment, so please correct me, but there was a fully staffed team at Meta that maintained it, but was not in the best place to manage the issues?

They said the team was not in a great place to do it, eg. they probably had competing priorities that overshadowed triaging issues.

Re: Jemalloc Postmortem

#174

Post by durrrrrrrrrrrrr »

kstrauser wrote: post #164
dwattttt wrote: post #150

Earlier quoted context omitted.

Allowing SIMD instructions to be used arbitrarily in kernel actually has a fair penalty to it. I'm not sure what Linux does specifically, but: When a syscall is made, the kernel has to backup the user mode state of the thread, so it can restore it later. If any kernel code could use SIMD registers, you'll have to backup and restore that too, and those registers get big. You could easily be looking at adding a 1kb cop…

Why is that? Couldn’t there be push_simd()/pop_simd() that the syscall itself uses around its SIMD calls? If no syscalls use SIMD today, I’d think we’re starting from a safe position.

push_simd/pop_simd exist and are called kernel_fpu_begin/kernel_fpu_end. Their use is practically prohibited in most areas and iiuc not available on all archs, but it's available if needed.

Re: Jemalloc Postmortem

#175

Post by zozbot234 »

pvg wrote: post #172
zozbot234 wrote: post #171

Earlier quoted context omitted.

[flagged]

Project participants showing up to HN to discuss their work is one of the more interesting and valuable things we have here and a 'community norm' in which they start getting hectored over tiny details or pet issues unrelated to the work would not be a good one - it just drives people away.

Fully agreed! Thanks for providing your own perspective.

Re: Jemalloc Postmortem

#176

Post by pkhuong »

Aissen wrote: post #96
masklinn wrote: post #65

> jemalloc was probably booted from Rust binaries sooner than the natural course of development might have otherwise dictated. FWIW while it was a factor it was just one of a number: https://github.com/rust-lang/rust/issues/36963#issuecomment-... And jemalloc was only removed two years after that issue was opened: https://github.com/rust-lang/rust/pull/55238

Interesting that one of the factor listed in there, the hardcoded page-size on arm64, is still is an unsolved issue upstream, and that forces app developers to either ship multiple arm64 linux binaries, or drop support for some platforms. I wonder if some kind of dynamic page-size (with dynamic ftrace-style binary patching for performance?) would have been that much slower.

You can run jemalloc configured with 16KB pages on a 4KB page system.

Re: Jemalloc Postmortem

#177

Post by keybored »

jeffbee wrote: post #158
p0w3n3d wrote: post #53

Thank you. Jemalloc was recently recommended to me on some presentation about Java optimization. I wonder if you did get everything you should from the companies that use it. I mean sometimes I feel that big tech firms only use free software, never giving anything to it, so I hope you were the exception here.

Imagine being a Java developer and thinking "what have big tech corporations ever done for me?"

That are good for me, the developer.

Re: Jemalloc Postmortem

#178

Post by const_cast »

Cloudef wrote: post #137
the_mitsuhiko wrote: post #117

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 devel…

malloc is bad api in general, if you want to go fast you don't rely on general purpose allocator

This is true, but the unfortunate thing with how C and C++ were developed is that pretty much everything just assumes the existence of malloc/free. So if you’re using third-party libraries then it’s out of your control mostly. Linking a new allocator is a very easy and pretty much free way to improve performance.

Re: Jemalloc Postmortem

#179

Post by const_cast »

mrweasel wrote: post #139

Looking at all the comments and lightly browsing the source code, I'm amazed. Both at how much impact a memory allocator can make, but also how much code is involved. I'm not really sure what I expected, but somehow I expect a memory allocator to be ... smaller, simpler perhaps?

It’s the same way with garbage collectors.

You can write a naive mark-and-sweep in an afternoon. You can write a reference counter in even less time. And for some runtimes this is fine.

But writing a generational, concurrent, moving GC takes a lot of time. But if you can achieve it, you can get amazing performance gains. Just look at recent versions of Java.

Re: Jemalloc Postmortem

#180

Post by toast0 »

jeffbee wrote: post #155
nicoburns wrote: post #120

Earlier quoted context omitted.

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

In the containerized environments where these allocators were mainly developed, it is all but totally pointless to return memory to the kernel. You might as well keep everything your container is entitled to use, because it's not like the other containers can use it. Someone or some automatic system has written down how much memory the container is going to use.

Returning no longer used anonymous memory is not without benefits.

Returning pages allows them to be used for disk cache. They can be zeroed in the background by the kernel which may save time when they're needed again, or zeroing can be avoided if the kernel uses them as the destination of a full page DMA write.

Also, returning no longer used pages helps get closer to a useful memory used measurement. Measuring memory usage is pretty difficult of course, but making the numbers a little more accurate helps.

Post reply on HN