Meta’s renewed commitment to jemalloc

https://engineering.fb.com/2026/03/02/data-infrastructure/investing-in-infrastructure-metas-renewed-commitment-to-jemalloc/

by hahahacorn • 4 months ago

515 221 4 months ago

engineering.fb.com

https://github.com/jemalloc/jemalloc

thatoneengineer• 4 months ago

First impressions: LOL, the blunt commentary in the HN thread title compared to the PR-speak of the fb.com post.

Second thoughts: Actually the fb.com post is more transparent than I'd have predicted. Not bad at all. Of course it helps that they're delivering good news!

MBCook• 4 months ago

It’s still quite corporate-y, but other than the way of writing I agree it’s generally quite clear.

oncallthrow• 4 months ago

And the Oscar for most mealy-mouthed post of the year goes to…

dang2• 4 months ago

We generally try to avoid corporate press releases for that reason, but is there a good third-party post to replace it with?

https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor...

fermentation• 4 months ago

Seems like they’d want to wait to commit until after the layoffs, right?

OsrsNeedsf2P• 4 months ago

I work in the space. This article would not have been published if the team responsible was on the chopping block

kubb• 4 months ago

It's just one team with like 4 people. They can layoff a lot of staff from Metaverse.

bmenrigh2• 4 months ago

I recently started using Microsoft's mimalloc (via an LD_PRELOAD) to better use huge (1 GB) pages in a memory intensive program. The performance gains are significant (around 20%). It feels rather strange using an open source MS library for performance on my Linux system.

There needs to be more competition in the malloc space. Between various huge page sizes and transparent huge pages, there are a lot of gains to be had over what you get from a default GNU libc.

sylware2• 4 months ago

If there is so much performance difference among generic allocators, it means you need semantic optimized allocators (unless performance is actually not that much important in the end).

Cloudef• 4 months ago

You are not wrong and this is indeed what zig is trying to push by making all std functions that allocate take a allocator parameter.

codexon3• 4 months ago

Agreed mostly. Going from standard library to something like jemalloc or tcmalloc will give you around 5-10% wins which can be significant, but the difference between those generic allocators seem small. I just made a slab allocator recently for a custom data type and got speedups of 100% over malloc.

adgjlsfhk15• 4 months ago

One of the best parts about GC languages is they tend to have much more efficient allocation/freeing because the cost is much more lumped together so it shows up better in a profile.

pjmlp5• 4 months ago

Agreed, however there is also a reason why the best ones also pack multiple GC algorithms, like in Java and .NET, because one approach doesn't fit all workloads.

bluGill2• 4 months ago

When it works. Many programs in GC language end up fighting the GC by allocating a large buffer and managing it by hand anyway because when performance counts you can't have allocation time in there at all. (you see this in C all the time as well)

CyberDildonics8• 4 months ago

Any extra throughput is far overshadowed by trying to control pauses and too much heap allocations happening because too much gets put on the heap. For anything interactive the options are usually fighting the gc or avoiding gc.

pjmlp5• 4 months ago

If you go into Dr Dobbs, The C/C++ User's Journal and BYTE digital archives, there will be ads of companies whose product was basically special cased memory allocator.

Even toolchains like Turbo Pascal for MS-DOS, had an API to customise the memory allocator.

The one size fits all was never a solution.

codexon3• 4 months ago

I've been using jemalloc for over 10 years and don't really see a need for it to be updated. It always holds up in benchmarks against any new flavor of the month malloc that comes out.

Last time I checked mimalloc which was admittedly a while ago, probably 5 years, it was noticebly worse and I saw a lot of people on their github issues agreeing with me so I just never looked at it again.

adgjlsfhk15• 4 months ago

Mimalloc v3 has just come out (about a month ago) and is a significant improvement over both v2 and v1 (what you likely last tested)

jeffbee6• 4 months ago

Just out of curiosity are you getting 1GB huge pages on Xeon or some other platform? I always thought this class of page is the hardest to exploit, considering that the machine only has, if I recall correctly, one TLB slot for those.

bmenrigh2• 4 months ago

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 that there are a ton of configurable knobs available via env vars. I'm able to hand those 16 1 GiB pages to the program at launch via `MIMALLOC_RESERVE_HUGE_OS_PAGES=16`.

EDIT: after re-reading your comment a few times, I apologize if you already knew this (which it sounds like you did).

IshKebab• 4 months ago

I feel like the real thing that needs to change is we need a more expressive allocation interface than just malloc/realloc. I'm sure that memory allocators could do a significantly better job if they had more information about what the program was intending to do.

liuliu• 4 months ago

There are, look no further than jemalloc API surface itself:

https://jemalloc.net/jemalloc.3.html

One thing to call out: sdallocx integrates well with C++'s sized delete semantics: https://isocpp.org/files/papers/n3778.html

anthk• 4 months ago

I used mimalloc to run zenlisp under OpenBSD as it would clash with the paranoid malloc of base.

pocksuppet• 4 months ago

In many cases you can also do better than using malloc e.g. if you know you need a huge page, map a huge page directly with mmap

Yes, if you want to use huge pages with arbitrary alloc/free, then use a third-party malloc. If your alloc/free patterns are not arbitrary, you can do even better. We treat malloc as a magic black box but it's actually not very good.

skavi5• 4 months ago

We evaluated a few allocators for some of our Linux apps and found (modern) tcmalloc to consistently win in time and space. Our applications are primarily written in Rust and the allocators were linked in statically (except for glibc). Unfortunately I didn't capture much context on the allocation patterns. I think in general the apps allocate and deallocate at a higher rate than most Rust apps (or more than I'd like at least).

Our results from July 2025:

rows are <allocator>: <RSS>, <time spent for allocator operations>

  app1:
  glibc: 215,580 KB, 133 ms
  mimalloc 2.1.7: 144,092 KB, 91 ms
  mimalloc 2.2.4: 173,240 KB, 280 ms
  tcmalloc: 138,496 KB, 96 ms
  jemalloc: 147,408 KB, 92 ms

  app2, bench1
  glibc: 1,165,000 KB, 1.4 s
  mimalloc 2.1.7: 1,072,000 KB, 5.1 s
  mimalloc 2.2.4:
  tcmalloc: 1,023,000 KB, 530 ms

  app2, bench2
  glibc: 1,190,224 KB, 1.5 s
  mimalloc 2.1.7: 1,128,328 KB, 5.3 s
  mimalloc 2.2.4: 1,657,600 KB, 3.7 s
  tcmalloc: 1,045,968 KB, 640 ms
  jemalloc: 1,210,000 KB, 1.1 s

  app3
  glibc: 284,616 KB, 440 ms
  mimalloc 2.1.7: 246,216 KB, 250 ms
  mimalloc 2.2.4: 325,184 KB, 290 ms
  tcmalloc: 178,688 KB, 200 ms
  jemalloc: 264,688 KB, 230 ms

tcmalloc was from github.com/google/tcmalloc/tree/24b3f29.

i don't recall which jemalloc was tested.

hedora3• 4 months ago

I’m surprised (unless they replaced the core tcmalloc algorithm but kept the name).

tcmalloc (thread caching malloc) assumes memory allocations have good thread locality. This is often a double win (less false sharing of cache lines, and most allocations hit thread-local data structures in the allocator).

Multithreaded async systems destroy that locality, so it constantly has to run through the exception case: A allocated a buffer, went async, the request wakes up on thread B, which frees the buffer, and has to synchronize with A to give it back.

Are you using async rust, or sync rust?

ComputerGuru• 4 months ago

That’s a considerable regression for mimalloc between 2.1 and 2.2 – did you track it down or report it upstream?

Edit: I see mimalloc v3 is out – I missed that! That probably moots this discussion altogether.

codexon3• 4 months ago

This is similar to what I experienced when I tested mimalloc many years ago. If it was faster, it wasn't faster by much, and had pretty bad worst cases.

m463• 4 months ago

I remember in the early days of web services, using the apache portable runtime, specifically memory pools.

If you got a web request, you could allocate a memory pool for it, then you would do all your memory allocations from that pool. And when your web request ended - either cleanly or with a hundred different kinds of errors, you could just free the entire pool.

it was nice and made an impression on me.

I think the lowly malloc probably has lots of interesting ways of growing and changing.

jra_samba• 4 months ago

Look into talloc, used inside Samba (and other FLOSS projects like sssd). Exactly this.

Sesse__• 4 months ago

This is called “an arena” more generally, and it is in wide use across many forms of servers, compilers, and others.

Dylan168075• 4 months ago

I think some operating system improvements could get people motivated to use huge pages a lot better. In particular make them less fragile on linux and make them not need admin rights on windows. The biggest factor causing problems there is that neither OS can swap a 2MB page. So someone needs to care enough to fix that.

dang2• 4 months ago

Related. Others?

Jemalloc Postmortem - https://news.ycombinator.com/item?id=44264958 - June 2025 (233 comments)

Jemalloc Repositories Are Archived - https://news.ycombinator.com/item?id=44161128 - June 2025 (7 comments)

markstos• 4 months ago

How is the original author making out in the new arrangement?

Aurornis• 4 months ago

Jason Evans worked for Facebook for almost two decades, starting in 2009 - https://jasone.github.io/2025/06/12/jemalloc-postmortem/

He's doing just fine. If you're looking for a story about a FAANG company not paying engineers well for their work, this isn't it.

bfgeek• 4 months ago

One has to wonder if this due to the global memory shortage. ("Oh - changing our memory allocator to be more efficient will yield $XXM dollar savings over the next year").

augusto-moura• 4 months ago

Not just shortage, any improvements to LLMs/electricity/servers memory footprint is becoming much more valuable as the time goes. If we can get 10% faster, you can easily get a lead in the LLM race. The incentives to transparently improving performance are tremendous

runevault• 4 months ago

On top of cost, they probably cannot get as much memory as they order in a timely fashion so offsetting that with greater efficiency matters right now.

bluGill2• 4 months ago

Facebook had talks already years ago (10+) - nobody was allowed to share real numbers, but several facebook employed where allowed to share that the company has measured savings from optimizations. Reading between the lines, a 0.1% efficiency improvement to some parts of Facebook would save them $100,000 a month (again real numbers were never publicly shared so there is a range - it can't be less than $20,000), and so they had teams of people whose job it was to find those improvements.

Most of the savings seemed to come from HVAC costs, followed by buying less computers and in turn less data centers. I'm sure these days saving memory is also a big deal but it doesn't seem to have been then.

The above was already the case 10 years ago, so LLMs are at most another factor added on.

alex1138• 4 months ago

I've heard of some people getting banned from FB to save memory space? Surely that can't be the case but I swear I've seen something like that

HackerThemAll• 4 months ago

LLMs are at most another factor added on

At most... Think 10x rather than 0.1x or 1x.

sethhochberg• 4 months ago

I don't have many regrets about having spent my career in (relatively) tiny companies by comparison, but it sure does sound fun to be on the other side for this kind of thing - the scale where micro-optimizations have macro impact.

In startups I've put more effort into squeezing blood from a stone for far less change; even if the change was proportionally more significant to the business. Sometimes it would be neat to say "something I did saved $X million dollars or saved Y kWh of energy" or whatever.

Anon1096• 4 months ago

I've worked on optimizing systems in that ballpark range, memory is worth saving but it isn't necessarily 1:1 with increasing revenue like CPU is. For CPU we have tables to calculate the infra cost savings (we're not really going to free up the server, more like the system is self balancing so it can run harder with the freed CPU), but for memory as long as we can load in whatever we want to (rec systems or ai models) we're in the clear so the marginal headroom isn't as important. It's more of a side thing that people optimizing CPU also get wins in by chance because the skillsets are similar.

loeg• 4 months ago

Yeah, identifying single-digit millions of savings out of profiles is relatively common practice at Meta. It's ~easy to come up with a big number when the impact is scaled across a very large numbers of servers. There is a culture of measuring and documenting these quantified wins.

foobarian• 4 months ago

Oooh maybe finally time for lovingly hand-optimized assembly to come back in fashion! (It probably has in AI workloads or so I daydream)

celdon252• 4 months ago

With the reputation of that company, one can wonder a lot of backstories that are even more depressing than a memory shortage.

mathisfun123• 4 months ago

changing our memory allocator

they've been using jemalloc (and employing "je") since 2009.

charcircuit2• 4 months ago

Meta never abandoned jemalloc. https://github.com/facebook/jemalloc remained public the entire time. It's my understanding that Jason Evans, the creator of jemalloc, had ownership over the jemalloc/jemalloc repo which is why that one stopped being updated after he left.

kstrauser2• 4 months ago

The repo's availability isn't related to whether it's still maintained.

charcircuit2• 4 months ago

Meta still maintained it and actively pushed commits to it fixing bugs and adding improvements. From this blog post it sounds like they are increasing investment into it along with resurrecting the original repo. When the repo was archived Meta said that development on jemalloc would be focused towards Meta's own goals and needs as opposed to the larger ecosystem.

nubinetwork• 4 months ago

Someone should tell Bryan Cantrill, he'd probably be ecstatic...

RegnisGnaw• 4 months ago

Is there a concise timelime/history of this? I thought jemalloc was 100% open source, why is Meta in control of it?

masklinn2• 4 months ago

Jason Evans (the creator of jemalloc) recounted the entire thing last year: https://jasone.github.io/2025/06/12/jemalloc-postmortem/

vintermann• 4 months ago

"Were I to reengage, the first step would be at least hundreds of hours of refactoring to pay off accrued technical debt."

Facebook's coding AIs to the rescue, maybe? I wonder how good all these "agentic" AIs are at dreaded refactoring jobs like these.

echelon• 4 months ago

If you filter the commits to the past five years, four of the top six committers are Meta employees. The other two might be as well, it just doesn't say that on their Github / personal website.

flykespice2• 4 months ago

Jemalloc also is used by android bionic libc library

tonfa• 4 months ago

Doesn't it depend on vendors/customization? Default is https://llvm.org/docs/ScudoHardenedAllocator.html since Android 11 (2020).

flykespice2• 4 months ago

I don't know, that is probably the case I guess?

I was recently debugging an app double-free segfault on my android 13 samsung galaxy A51 phone, and the internal stack trace pointed to jemalloc function calls (je_free).

larsberg• 4 months ago

scudo has been the default allocator for Android since Android 11, and we are hoping to make it mandatory for the few remaining places that don't use it. Using an allocator without memory protections in 2026 (especially after we have closed nearly all known performance gaps with jemalloc) is really not a great choice.

xxs7• 4 months ago

Few months back, some of the services switched to jemalloc for the Java VM. It took months (of memory dumps and tracing sys-calls) to blame the JVM, itself, for getting killed by the oom_killer.

Initially the idea was diagnostics, instead the the problem disappeared on its own.

yxhuvud• 4 months ago

If you changed from glibc to jemalloc and that solved your issues, then you should blame glibc, not the JVM.

xxs7• 4 months ago

Well, indeed - I thought that part was obvious reading it.

pram• 4 months ago

I used jemalloc recently for ComfyUI/Wan and it’s literally magic. I’m surprised it doesn’t come that way by default.

jeffbee6• 4 months ago

Allocators like that aren't the default for every process because they have higher startup costs. They are targeted to server workloads where startup cost doesn't matter, but it matters a lot if you're doing crud like starting millions of short-lived processes.

senderista• 4 months ago

I don't think glibc malloc makes an optimal set of tradeoffs for any scenario.

starkparker2• 4 months ago

(wrong thread)

gcr• 4 months ago

The URL of this story seems to have changed to a Meta press release. What are you quoting?

starkparker2• 4 months ago

Sorry, misdirected the reply.

jjuliano• 4 months ago

I remember I was a senior lead softeng of a worldbank funded startup project, and have deployed Ruby with jemalloc in prod. There's a huge noticeable speed and memory efficiency. It did saved us a lot of AWS costs, compare to just using normal Ruby. This was 8 years ago, why haven't projects adopt it yet as de facto.

kortex• 4 months ago

Usually lack of knowledge that such a thing exists, or just plain ol' momentum. Changing something long in production at established companies, even if there is a tangible benefit, can be a real challenge.

lobf• 4 months ago

We are committed to continuing to develop jemalloc development

From the Department of Redundancy Department.

adsharma8• 4 months ago

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 the kernel and then have it allocate it in another thread's pool.

One problem: this involves zero'ing memory, which has an impact on cache locality and over all app performance. It's completely unnecessary if the page is being recirculated within the same security domain.

The problem was getting everyone to agree on what that security domain is, even if the mechanism was opt-in.

https://marc.info/?l=linux-kernel&m=132691299630179&w=2

jcalvinowens3• 4 months ago

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 an advantage at the system level when challenged on it, and that's what matters.

adsharma8• 4 months ago

You probably weren't there when servers were running for many days at a time.

By the time you joined and benchmarked these systems, the continuous rolling deployment had taken over. If you're restarting the server every few hours, of course the memory fragmentation isn't much of an issue.

But you were unable to show an advantage at the system level when challenged on it, and that's what matters.

You mean 5 years after I stopped working on the kernel and the underlying system had changed?

I don't recall ever talking to you on the matter.

vardump• 4 months ago

I wouldn't be surprised if both 'adsharma' and 'jcalvinowens' were right, just at different points in time, perhaps in a bit different context. Things change.

google234123• 4 months ago

I like your clocks!

asveikau2• 4 months ago

Maybe I'm misreading, but considering it OK to leak memory contents across a process boundary because it's within a cgroup sounds wild.

adsharma8• 4 months ago

It wasn't any cgroup. If you put two untrusting processes in a memory cgroup, there is a lot that can go wrong.

If you don't like the idea of memory cgroups as a security domain, you could tighten it to be a process. But kernel developers have been opposed to tracking pages on a per address space basis for a long time. On the other hand memory cgroup tracking happens by construction.

genxy3• 4 months ago

What metrics were improved by your patches?

adsharma8• 4 months ago

Some more historical context. It wasn't a random optimization idea that I thought about in the shower and implemented the next day. Previous work on company wide profiling, where my contribution was low level perf_events plumbing:

https://research.google/pubs/google-wide-profiling-a-continu... https://engineering.fb.com/2025/01/21/production-engineering...

The profiling clearly showed kernel functions doing memzero at the top of the profiles which motivated the change. The performance impact (A/B testing and measuring the throughput) also showed a benefit at the point the change was committed.

This was when "facebook" was a ~1GB ELF binary. https://en.wikipedia.org/wiki/HipHop_for_PHP

The change stopped being impactful sometime after 2013, when a JIT replaced the transpiler. I'm guessing likely before 2016 when continuous deployment came into play. But that was continuously deploying PHP code, not HHVM itself.

By the time the patches were reevaluated I was working on a Graph Database, which sounded a lot more interesting than going back to my old job function and defending a patch that may or may not be relevant.

I'm still working on one. Guilty as charged of carrying ideas in my head for 10+ years and acting on them later. Link in my profile.

joelsiks• 4 months ago

Opening up strong with a gigantic merge of the stuff they've been working on in their own fork: https://github.com/jemalloc/jemalloc/pull/2863

rishabhjajoriya• 4 months ago

Large engineering orgs often underestimate how much CI pipelines amplify performance issues. Even small inefficiencies multiply when builds run hundreds of times a day.

jshorty2• 4 months ago

Surprised not to see any mention of the global memory supply shock. Would love to learn more about how that economic is shifting software priorities toward memory allocation for the first time in my (relatively young) career

twodave• 4 months ago

While it may seem directly related, it's just not. These things are worked on regardless of how cheap or expensive RAM is, because optimizing memory footprint pretty much always leads to fewer machines leased, which is a worthwhile goal even for smaller shops.

jshorty2• 4 months ago

That's useful to know, thank you.

refulgentis• 4 months ago

There’s been shocks at hyperscaler scale, ex. this got yuge at Google for a couple years before ChatGPT

m3kw9• 4 months ago

All the AI investment and their biggest news is commitment to Jemalloc

celdon252• 4 months ago

Building a software system is a lot like building a skyscraper: The product everyone sees is the top, but the part that keeps it from falling over is the foundation buried in the dirt and the scaffolding hidden from sight.

They should have just called it an ivory tower, as that's what they're building whenever they're not busy destroying democracy with OS Backdoor lobbyism or Cambridge Analytica shenanigans.

Edit: If every thread about any of Elon Musk's companies can contain at least 10 comments talking about Elon's purported crimes against humanity, threads about Zuckerberg's companies can contain at least 1 comment. Without reminders like this, stories like last week's might as well remain non-consequential.

carlos256• 4 months ago

If you need to optimize the allocator you are doing it wrong.

cbarrick• 4 months ago

Exactly. No need to engineer an allocator. You only live once!

    void* malloc(size_t size) {
        void *ptr = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_ANON, -1, 0);
        return (ptr == MAP_FAILED) ? NULL : ptr;
    }

    void free(void *ptr) { /* YOLO */ }

ot2• 4 months ago

That's a false dichotomy: you optimize both the application and the allocator.

A 0.5% improvement may not be a lot to you, but at hyperscaler scale it's well worth staffing a team to work on it, with the added benefit of having people on hand that can investigate subtle bugs and pathological perf behaviors.

sumtechguy• 4 months ago

exactly. I can think of at least 5 different projects I have been on where a better allocator would made a world of difference. I can also think of another 5 where it probably would have been a waste of time to even fiddle with.

but as usual there is an xkcd for that. https://xkcd.com/1205/

One project I spent a bunch of time optimizing the write path of I/O. It was just using standard fwrite. But by staging items correctly it was an easy 10x speed win. Those optimizations sometimes stack up and count big. But it also had a few edges on it, so use with care.

saagarjha• 4 months ago

Glad we have super slow allocators then

apatheticonion4• 4 months ago

As an Australian who was just made redundant from a role that involved this type of low level programming - I love working on these these kinds of challenges.

I'm saddened that the job market in Australia is largely React CRUD applications and that it's unlikely I will find a role that lets me leverage my niche skill set (which is also my hobby)

ajxs• 4 months ago

Speaking as an Australian that works on React CRUD applications because there's nothing else in the market, I've been reading through this thread thinking the exact same thing.

apatheticonion4• 4 months ago

Google had some position open working on the kernel for ChromeOS, and Microsoft had some positions working on data center network drivers.

I applied for both and got ghosted, haha.

I also saw a government role as a security researcher. Involves reverse engineering, ghidra and that sort of thing. Super awesome - but the pay is extremely uncompetitive. Such a shame.

Other than that, the most interesting roles are in finance (like HFT) - where you need to juggle memory allocations, threads and use C++ (hoping I can pitch Rust but unlikely).

Sadly they have a reputation of having pretty rough cultures, uncompetitive salaries and it's all in-office

Pepe1vo• 4 months ago

Not sure if it's the domain you're interested in, but there are quite a few HFT firms with offices in Australia.

The one I know of (IMC trading) does a lot of low level stuff like this and is currently hiring.

apatheticonion4• 4 months ago

I'm actually looking at HFT companies. Hoping I find one that allows remote working - but looks like there are basically no remote roles going at the moment

apatheticonion4• 4 months ago

I just tried to apply for IMC, the form on their careers page is broken. Looks like that's the first boss to defeat, haha

gzread4• 4 months ago

I have a relative in Australia who was hired by some type of consultancy to work on Samba, but I don't know what work he was doing.

pabs35• 4 months ago

Which consultancy was that?

amacneil2• 4 months ago

I know this isn’t who’s hiring thread, but we are hiring in AU for low-level data processing and have interesting performance challenges.

Link in bio.

maxwindiff• 4 months ago

Love your product!

profquail• 4 months ago

SIG is hiring for some roles in Sydney: https://careers.sig.com/global-experienced

pabs35• 4 months ago

Some of this remote stuff might interest you:

https://www.igalia.com/jobs/open/

pabs35• 4 months ago

Or https://www.fsf.org/resources/jobs/fsf-engineering-and-certi...

lukeh• 4 months ago

I hear you. Actually I read this thread because we’re using jemalloc in an embedded product. The only way I found to work on interesting problems here was to work for myself. (Having said that I think Apple might have some security research in Canberra? Years ago there was LinuxCare there and a lot of smart people. But that was in 2003…)

Sarkie• 4 months ago

I nice use case too

https://technology.blog.gov.uk/2015/12/11/using-jemalloc-to-...

wengo314• 4 months ago

jemalloc saved my icinga2 installation that kept exploding in memory usage, when i (and agents from sub-zones) was hammering its api

when i preloaded jemalloc , memory remained at significantly lower levels, and - more importantly - it was stable.

there seems to be no single correct solution to memory allocation, depending on the workload

agnishom• 4 months ago

Glad to see the commitment towards important non-LLM projects!

robertlagrant• 4 months ago

With the leverage jemalloc provides however, it can be tempting to realize some short-term benefit. It requires strong self-discipline as an organization to resist that temptation and adhere to the core engineering principles.

This doesn't quite read properly to me. What does it actually mean, does anyone know?

gjm11• 4 months ago

I'm pretty sure it means something like this: "Because jemalloc is used all over the place in our systems that run at tremendous scale, some hack that improves its performance a little bit while degrading the longer-term maintainability of the code can look very appealing -- look, doing this thing will save us $X,000,000 per year! -- and it takes discipline to avoid giving in to that temptation and to insist on doing things properly even if sometimes it means passing up a chance to make the code 0.1% faster and 10% messier."

throwaway2046• 4 months ago

https://archive.ph/CFQBU

mywacaday• 4 months ago

The only option for cookies is to accept these terms and conditions, I thought implied consent was explicitly not allowed due to GDPR?

"To help personalize content, tailor and measure ads and provide a safer experience, we use cookies. By clicking or navigating the site, you agree to allow our collection of information on and off Facebook through cookies. Learn more, including about available controls:

https://engineering.fb.com/privacy"

flippyhead• 4 months ago

Jemalloc and Jalad at Tanagra!

fhn• 4 months ago

this is just meta wanting people to test and fix. they don't care about it but they want you to

Asm2D• 4 months ago

It would be great if Meta was able to sustain to support more open source projects, especially those they benefit from.

For example they use AsmJit in a lot of projects (both internal and open-source) and it's now unmaintained because of funding issues. Maybe they have now internal forks too.

Meta’s renewed commitment to jemalloc

Related Stories