Meta: Neue Investitionen in jemalloc und stärkere Open-Source-Zusammenarbeit

 (engineering.fb.com)
2 Punkte von GN⁺ 2026-03-17 | 1 Kommentare | Auf WhatsApp teilen
  • Der High-Performance-Speicherallokator jemalloc ist seit langem eine grundlegende Komponente, die im Meta-Software-Stack neben dem Linux-Kernel und Compilern als zentrale Infrastruktur dient
  • In den vergangenen Jahren entfernte sich die Entwicklung von jemalloc schrittweise von den zentralen Engineering-Prinzipien, die das Projekt getragen hatten, wodurch sich technische Schulden anhäuften und der Fortschritt gebremst wurde
  • Nach Aufnahme von Community-Feedback und Gesprächen mit Mitgliedern einschließlich Projektgründer Jason Evans wurde das ursprüngliche Open-Source-Repository wieder aktiviert (unarchived)
  • Künftig will man sich auf den Abbau technischer Schulden, Verbesserungen am Huge-Page-Allokator, eine höhere Speichereffizienz und AArch64-Optimierungen konzentrieren
  • Meta bekräftigt seine langfristige Stewardship für jemalloc und richtet sich stärker auf die Weiterentwicklung des Projekts in Zusammenarbeit mit der Community aus

Rolle und Bedeutung von jemalloc

  • jemalloc ist ein High-Performance-Speicherallokator und eine Komponente, die im Meta-Software-Stack durchgängig großen Hebel entfaltet hat
  • Die Software hat sich fortlaufend an Veränderungen der Hardware und der Software in höheren Schichten angepasst und trägt gemeinsam mit dem Linux-Kernel und Compilern zur Stabilität und Leistung der Meta-Infrastruktur bei

Abkehr von den Prinzipien und Selbstreflexion

  • Grundlegende Softwarekomponenten erfordern im Spannungsfeld zwischen Pragmatismus und Prinzipientreue ein Höchstmaß an Strenge
  • Wegen des großen Hebels von jemalloc besteht die Versuchung, kurzfristige Vorteile zu realisieren; um dem zu widerstehen, braucht es auf Organisationsebene starke Selbstdisziplin
  • In den vergangenen Jahren kam es zu einer schrittweisen Abkehr von den zentralen Engineering-Prinzipien, die die Entwicklung von jemalloc geleitet hatten
  • Einige Entscheidungen brachten unmittelbare Vorteile, doch die daraus entstandenen technischen Schulden behinderten den Fortschritt
  • Das Community-Feedback wurde ernst genommen, und es fanden Gespräche mit Community-Mitgliedern statt, darunter Projektgründer Jason Evans
  • Meta hat tiefgehend reflektiert, wie sich seine Stewardship auf die langfristige Gesundheit von jemalloc ausgewirkt hat, und einen geänderten Ansatz vorgestellt
  • Die Arbeit am Abbau technischer Schulden und am Neuaufbau einer langfristigen Roadmap für jemalloc wurde aufgenommen

Ein neues Kapitel: Entarchivierung des Repositorys und weitere Pläne

  • Als Ergebnis der Gespräche mit der Community wurde das ursprüngliche Open-Source-Repository von jemalloc wieder aktiviert (unarchived)
  • Dadurch kann Meta die Steward-Rolle für das Projekt fortführen und sich darauf konzentrieren, den Wartungsaufwand zu senken und die Codebasis zu modernisieren
    • Abbau technischer Schulden: Durch Refactoring und Verbesserungen soll jemalloc für alle Nutzer effizient, zuverlässig und einfach einsetzbar bleiben
    • Huge-Page-Allokator (HPA): Transparent Hugepages (THP) sollen besser genutzt werden, um die CPU-Effizienz zu steigern
    • Speichereffizienz: Die Speichereffizienz optimieren durch Verbesserungen bei Packing-, Caching- und Purging-Mechanismen
    • AArch64-Optimierungen: Auf ARM64-Plattformen soll bereits im Standardzustand eine gute Performance gewährleistet sein

Stärkere Zusammenarbeit mit der Community

  • Meta betont den Aufbau von Vertrauen durch Taten und strebt eine gesunde Weiterentwicklung von jemalloc an
  • Feedback und Beteiligung aus der Community sind willkommen, und Meta freut sich darauf, gemeinsam die Zukunft von jemalloc zu gestalten
  • Im Open-Source-Ökosystem soll auf nachhaltige Zusammenarbeit und Weiterentwicklung hingearbeitet werden

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2026-03-17
Hacker-News-Kommentare

  • Während meiner Zeit bei Facebook habe ich einen Kernel-Patch gepflegt, um den Purging-Mechanismus von jemalloc zu verbessern.
    Im Kernel- oder Security-Umfeld war er nicht besonders beliebt, in Benchmarks aber effizient.
    Das Problem war, dass beim erneuten Zuweisen von Speicher an einen anderen Thread Zeroing stattfand, was Cache-Lokalität und Performance beeinflusste.
    Wenn Speicher innerhalb derselben Sicherheitsdomäne wiederverwendet wurde, war das unnötig, aber es war schwer, sich darauf zu einigen, wie weit eine „Sicherheitsdomäne“ definiert werden sollte.
    Die zugehörige Diskussion findet sich auf der Linux-Kernel-Mailingliste.

    • Es überrascht mich, dass dieser Patch immer noch erwähnt wird.
      Wir haben in HHVM umfangreiche Benchmarks vor und nach Anwendung des Patches durchgeführt, aber auf Systemebene gab es keinen statistisch signifikanten Unterschied.
      Bei einigen Mikrobenchmarks mag es Verbesserungen gegeben haben, aber da die Gesamtleistung des Systems nicht beeinflusst wurde, wurde er nicht in den Kernel aufgenommen.
    • Ich frage mich, welche Metrik sich verbessert hat.
    • Die Annahme, dass es innerhalb einer cgroup in Ordnung sei, wenn Speicherinhalte zwischen Prozessen durchsickern, klingt nach einer riskanten Idee.

  • Ich habe kürzlich Microsofts mimalloc per LD_PRELOAD verwendet, um 1-GB-Huge Pages zu nutzen.
    Bei einem speicherintensiven Programm habe ich etwa 20 % Leistungssteigerung erzielt.
    Es fühlt sich irgendwie seltsam an, unter Linux mit einer Open-Source-MS-Bibliothek die Performance zu steigern.
    Ich finde, der malloc-Bereich braucht mehr Wettbewerb.

    • Ich habe mehrere Allocatoren getestet, und das aktuelle tcmalloc zeigte sowohl bei Zeit als auch Speicher die besten Ergebnisse.
      Es waren in Rust geschriebene Apps, die größtenteils statisch gelinkt waren.
      Zum Beispiel zeigte tcmalloc bei app1 gegenüber glibc 35 % weniger RSS und 30 % kürzere Verarbeitungszeit.
      Die Gesamtergebnisse wurden auf Basis des tcmalloc-Repositorys getestet.
    • Früher gab es in Zeitschriften wie Dr. Dobbs oder BYTE viele Anzeigen für benutzerdefinierte Speicher-Allocatoren.
      Sogar Turbo Pascal bot eine API, mit der man den Speicher-Allocator direkt definieren konnte.
      Letztlich hatte der „One size fits all“-Ansatz schon vor langer Zeit seine Grenzen.
    • Einer der Vorteile von GC-Sprachen ist, dass Allokations-/Freigabekosten gebündelt sind und beim Profiling dadurch klarer sichtbar werden.
    • Das Konzept der Memory Pools im alten Apache Portable Runtime fand ich beeindruckend.
      Pro Request wurde ein Pool erstellt, und wenn der Request beendet war, wurde alles auf einmal freigegeben.
      Ich denke, malloc hat noch viel Spielraum, sich in diese Richtung weiterzuentwickeln.
    • Je nach Fall ist es effizienter, statt malloc direkt Huge Pages per mmap zu mappen.
      Wenn das Allokationsmuster einfach ist, kann das bessere Ergebnisse liefern als ein Third-Party-malloc.
      Viele sehen malloc als magische Blackbox, aber so großartig ist es in Wirklichkeit nicht.

  • Unser Team ist vor zwei Jahren von glibc malloc auf jemalloc migriert.
    Bei Python-Services sank der Speicherverbrauch um 15 bis 20 %.
    In Container-Umgebungen war es allerdings wichtig, oversize_threshold anzupassen — bei falscher Einstellung kam es zu OOM.
    Ich frage mich, ob es Benchmarks gibt, die jemalloc und mimalloc bei langlaufenden Services vergleichen.

  • Als weiterführende Lektüre empfehle ich Jemalloc Postmortem und
    Jemalloc Repositories Are Archived.

  • Ich frage mich, ob diese Änderung vielleicht auf einen globalen Speichermangel zurückzuführen ist.
    Da könnte leicht eine Rechnung wie „durch Austausch des Memory-Allocators mehrere Millionen Dollar pro Jahr gespart“ herauskommen.

    • Facebook verfolgte schon vor zehn Jahren Gewinnsteigerungen durch Mikrooptimierungen.
      Schon 0,1 % Effizienzgewinn konnten 100.000 Dollar pro Monat einsparen.
      Die Hauptgründe für die Einsparungen waren Kühlungskosten (HVAC) und weniger Serverkäufe.
      Heute ist Speichereinsparung ebenfalls ein großes Thema, damals war sie es noch nicht.
    • Es geht nicht nur um Kosten, sondern auch um Effizienzsteigerungen, um Verzögerungen in der Speicherlieferkette abzufedern.
    • Bei Meta ist es ganz normal, nach Einsparungen in Millionenhöhe zu suchen.
      Wenn eine Änderung Tausende Server betrifft, wirkt selbst eine kleine Verbesserung wie eine große Zahl.
      Diese Kultur quantitativer Verbesserungen ist dort fest verankert.
    • Wenn man den Ruf des Unternehmens berücksichtigt, könnte es auch komplexere Gründe geben als bloßen Speichermangel.
    • LLMs, Stromverbrauch und Speichereffizienz von Servern werden immer wichtiger.
      Schon 10 % mehr Geschwindigkeit können im LLM-Wettbewerb einen Vorteil bringen.
      Der Anreiz für Leistungsverbesserungen ist enorm.

  • Ich wurde in Australien während meiner Arbeit an Low-Level-Programmierung entlassen.
    Ich liebe es wirklich, solche Probleme zu lösen, aber der lokale Markt besteht leider größtenteils aus React-CRUD.

    • In Australien wird im Bereich datennahe Low-Level-Verarbeitung eingestellt. Link im Profil.
    • Ich habe in Australien ebenfalls nur React-CRUD gemacht und genau dasselbe gedacht.
    • Wenn du nach Remote-Arbeit suchst, könnte die Igalia-Jobseite interessant sein.
    • HFT-Firmen (IMC trading) haben ebenfalls viele solcher Low-Level-Optimierungsaufgaben und stellen derzeit in Australien ein.
    • SIG sucht in Sydney ebenfalls für entsprechende Positionen: SIG Careers

  • In einem Startup-Projekt, das mit Mitteln der World Bank finanziert wurde, haben wir Ruby + jemalloc in Produktion ausgerollt.
    Geschwindigkeit und Speichereffizienz verbesserten sich deutlich, wodurch die AWS-Kosten stark sanken.
    Das ist acht Jahre her, und ich frage mich, warum jemalloc sich immer noch nicht als Standard etabliert hat.

    • Meist liegt es schlicht an fehlender Information oder Trägheit.
      Ein bereits laufendes System zu ändern, ist nicht einfach, selbst wenn der Nutzen klar ist.

  • Es gibt auch einen Fall, in dem jemalloc genutzt wurde, um die Ursache eines Speicherlecks nachzuverfolgen.
    Siehe den Technikblog von GOV.UK.

  • Meta hat in großem Umfang Inhalte zusammengeführt, an denen zuvor im eigenen Fork gearbeitet wurde.
    Das ist in PR #2863 zu sehen.

  • Ich frage mich, ob es Material gibt, das die Timeline oder Geschichte von jemalloc zusammenfasst.
    Es ist ein Open-Source-Projekt, also frage ich mich, warum Meta dort die Führung innehat.

    • Der Gründer Jason Evans hat letztes Jahr den gesamten Verlauf zusammengefasst.
      Siehe den Blogpost Jemalloc Postmortem.
    • Wenn man sich die Commits der letzten fünf Jahre ansieht, sind vier der sechs aktivsten Personen Meta-Mitarbeiter.
      Die beiden übrigen könnten ebenfalls im Verborgenen zu Meta gehören.