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

Meta’s renewed commitment to jemalloc

engineering.fb.com

Post reply on HN
Print view View original

251–259 of 259 posts

Re: Meta’s renewed commitment to jemalloc

#251

Post by CyberDildonics »

adgjlsfhk1 wrote: post #250
CyberDildonics wrote: post #247

Earlier quoted context omitted.

Modern C++ allocators don't use a heap structure either. "Yes, malloc uses a heap data structure to allocate memory dynamically for programs. The heap allows for persistent memory allocation that can be managed manually by the programmer." "How Malloc Works with the Heap Heap Data Structure: Malloc uses a heap data structure to manage memory. The heap is a region of a process's memory that is used for dynamic memory…

You're wrong for like 6 different reasons. Java does do bump pointer allocation. The key is that when GC runs, surviving objects get moved. The slow part of GC isn't the allocation (GCs generally have much faster allocators than malloc). The slow part is the barriers that the GC requires and the pauses.

You're wrong for like 6 different reasons.

If that were true you could have listed one the made sense in context. This person was saying that allocation was as fast as a incrementing a register while continually ignoring the fact that deallocation needs to happen along with any organization of allocated memory.

Then they were ignoring that large allocations have big speed benefits for a reason.

Conflating java moving a pointer, mapping memory into a process, sbrk, and arena allocation is going in circles, but the fundamentals that people need to fight the GC or work around it remains.

Allocations have a price and the first step to optimizing any program is avoiding that, but in GC languages you get pauses on top of your slow downs.

Re: Meta’s renewed commitment to jemalloc

#252

Post by Dylan16807 »

tosti wrote: post #206
bmenrigh wrote: post #37

Earlier quoted context omitted.

Modern x86_64 has supported multiple page sizes for a long time. I'm on commodity Zen 5 hardware (9900X) with 128 GiB of RAM. Linux will still use a base page size of 4kb but also supports both 2 MiB and 1 GiB huge pages. You can pass something like `default_hugepagesz=2M hugepagesz=1G hugepages=16` to your kernel on boot to use 2 MiB pages but reserve 16 1 GiB pages for later use. The nice thing about mimalloc is th…

> commodity > zen 5 > 128GiB Are you from the future?

I'm not sure what point you're trying to make.

In the middle of last year, a 9900X was around $350 and 128GB of memory was also around $350. That's very easily "commodity" range.

Re: Meta’s renewed commitment to jemalloc

#253

Post by pabs3 »

gzread wrote: post #227
pabs3 wrote: post #169

Earlier quoted context omitted.

Probably SerNet or one of the Samba Commercial Support companies like Catalyst: https://www.samba.org/samba/support/globalsupport.html

Might've been Catalyst. I see it's a NZ company not Australia.

I think Catalyst has an Australian presence too (and UK/CA):

https://www.catalyst-au.net/

Re: Meta’s renewed commitment to jemalloc

#254

Post by google234123 »

jcalvinowens wrote: post #138
adsharma wrote: post #72

> We plan to deliver improvements to [..] purging mechanisms During my time at Facebook, I maintained a bunch of kernel patches to improve jemalloc purging mechanisms. It wasn't popular in the kernel or the security community, but it was more efficient on benchmarks for sure. Many programs run multiple threads, allocate in one and free in the other. Jemalloc's primary mechanism used to be: madvise the page back to th…

I'm really surprised to see you still hocking this. We did extensive benchmarking of HHVM with and without your patches, and they were proven to make no statistically significant difference in high level metrics. So we dropped them out of the kernel, and they never went back in. I don't doubt for a second you can come up with specific counterexamples and microbenchnarks which show benefit. But you were unable to show…

I like your clocks!

Re: Meta’s renewed commitment to jemalloc

#255

Post by menaerus »

adsharma wrote: post #229
teiferer wrote: post #220

Earlier quoted context omitted.

Except one is an employee and the other one is an ex employee. The bias this introduces is not just a minor nuance, it's what fuels the public conflict and causes everybody else to double check their popcorn reserves. Of course technical discussions happen all the time at companies between competent people. But you don't do that in public, nor is this a technical debate: "I don't recall talking to you about it" - "I…

Important distinction yes. It also means I can't go back and check the thread on what was said and when. Nor do I want to. Always good to talk face to face if you're have strong feelings about something. When I said "talk" I meant literally face to face. Spending a decade or so on lkml, everyone develops a thick skin. But mix it with the corporate environment, Facebook 2011, being an ex-employee adds more to the dram…

Perf counters are only indicative of certain performance characteristics at the uarch level but when one improves one or more aspects of it the result does not necessarily positively correlate to the actual measurable performance gains in E2E workloads deployed on a system.

That said, one of the comments above suggests that the HW change was a switch to Ivy Bridge, when zeroing memory became cheaper, which is a bit unexpected (to me). So you might be more right when you say that the improvement was the result of memory allocation patterns and jemalloc.

Re: Meta’s renewed commitment to jemalloc

#256

Post by tosti »

Dylan16807 wrote: post #252
tosti wrote: post #206

Earlier quoted context omitted.

> commodity > zen 5 > 128GiB Are you from the future?

I'm not sure what point you're trying to make. In the middle of last year, a 9900X was around $350 and 128GB of memory was also around $350. That's very easily "commodity" range.

Damn. I feel old and must've missed that boat. Several other boats too, I guess.

Here I was thinking 16GiB is pretty good. I get to compile LibreOffice in an afternoon. QtWebEngine overnight.

Doesn't 128GiB make rowhammer much more feasible? You'd have 32GiB per DIMM.

Oh well

Re: Meta’s renewed commitment to jemalloc

#257

Post by Dylan16807 »

tosti wrote: post #256
Dylan16807 wrote: post #252

Earlier quoted context omitted.

I'm not sure what point you're trying to make. In the middle of last year, a 9900X was around $350 and 128GB of memory was also around $350. That's very easily "commodity" range.

Damn. I feel old and must've missed that boat. Several other boats too, I guess. Here I was thinking 16GiB is pretty good. I get to compile LibreOffice in an afternoon. QtWebEngine overnight. Doesn't 128GiB make rowhammer much more feasible? You'd have 32GiB per DIMM. Oh well

Two 64GiB DIMMs would be the more likely setup. The current CPUs strongly prefer having only one stick of DDR5 per channel.

The effectiveness of rowhammer depends on how well the manufacturer implemented target row refresh. But the internal ECC on DDR5 should help defend against it somewhat.

Personally I've been in the 24-32GiB range since 2013, and that's despite the fact that I'm still on DDR3.

Re: Meta’s renewed commitment to jemalloc

#258

Post by [deleted] »

alexgartrell wrote: post #146
adsharma wrote: post #144

Earlier quoted context omitted.

The patches were written in 2011 and published in 2012. They did what they were supposed to at the time. For the peanut gallery: this is a manifestation of an internal eng culture at fb that I wasn't particularly fond of. Celebrating that "I killed X" and partying about it. You didn't reply to the main point: did you benchmark a server that was running several days at a time? Reasonable people can disagree about whet…

For the peanut gallery more: I worked with both of these guys at Meta on this. The "servers are only on for a few hours" thing was like never true so I have no idea where that claim is coming from. The web performance test took more than a few hours to run alone and we had way more aggressive soaks for other workloads. My recollection was that "write zeroes" just became a cheaper operation between '12 and '14. A fun…

[deleted]

Re: Meta’s renewed commitment to jemalloc

#259

Post by themanualstates »

cogman10 wrote: post #122
CyberDildonics wrote: post #118

Earlier quoted context omitted.

Reinventing data structures poorly is very common. Heap allocation in java is something trivial happens constantly. People typically do funky stuff with memory allocation because they have to, because the GC is causing pauses. People avoid system allocators in C++ too, they just don't have to do it because of uncontrollable pauses.

> People typically do funky stuff with memory allocation because they have to This same dev did things like putting what he deemed as being large objects (icons) into weak references to save memory. When the references were collected, invariably they had to be reloaded. That was not the source of memory pressure issues in the app. I've developed a mistrust for a lot of devs "doing it because we have to" when it comes…

"This same dev did things like putting what he deemed as being large objects (icons) into weak references to save memory. When the references were collected, invariably they had to be reloaded."

Well actually, this is what the Apple[1] docs instruct devs to do. https://developer.apple.com/library/archive/documentation/Co...

For .NET on iOS, the difference between managed and unmanaged objects is of particular concern. In the example you provide, the Icon Assets are objects from an Apple Framework, not managed by .NET. You might use them in the UIKit views for list items in a UIKit List View.

iOS creates and disposes these list view items independently of .NET managed code. Because the reference counts can't be updated across these contexts, you'll inevitably end up with dangling references. This memory can't be cleared, so inadvertently using strong references will cause a memory leak that grows until your app crashes.

The following is a great explainer in the context of Xamarin for iOS. https://thomasbandt.com/xamarinios-memory-pitfalls

The above still applies with different languages / frameworks of course, however the difference is less explicit from a syntax perspective IMHO

Post reply on HN