The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Facebook возобновил разработку библиотеки управления памятью jemalloc

17.03.2026 12:06 (MSK)

Компания Meta* объявила о возобновлении разработки библиотеки управления памятью jemalloc, репозиторий которой в июне прошлого года был переведён в архивный режим. Библиотека jemalloc предлагает альтернативную реализацию функций malloc, оптимизированную для снижения фрагментации и работы на многопроцессорных системах.

Отмечается, что компания Meta осознала преимущества от применения jemalloc в своей инфраструктуре и решила возобновить работу над кодом данной библиотеки для снижения издержек на сопровождение, модернизации кодовой базы, избавления от технического долга и адаптации аллокатора для новых видов нагрузки и актуального оборудования. Разработка будет продолжена в форме открытого проекта, развиваемого совместно с сообществом и приветствующего подключение к работе сторонних участников.

Библиотека jemalloc была разработана Джейсоном Эвансом (Jason Evans) в 2005 году для FreeBSD 7.0, после чего была портирована в NetBSD и интегрирована в состав Firefox. В 2009 году автор jemalloc перешёл на работу в компанию Facebook, в которой данная библиотека использовалась во внутренних проектах. В 2017 году Джейсон уволился из Facebook, а разработка была продолжена оставшейся командой из Facebook. После переименования в Meta приоритеты компании изменились, развитие библиотеки застопорилось, разработка сосредоточилась только на внутренних потребностях, а общедоступная кодовая база со временем деградировала. Для поддержания общедоступной библиотеки на плаву требовался значительный рефакторинг, но Джейсон не готов был тратить своё время на эту работу и поэтому 10 месяцев назад перевёл репозиторий в архивный режим.

Среди планов, которые компания Facebook наметила реализовать после возрождения проекта:

  • Снижение накопленного технического долга, проведение рефакторинга и чистки кодовой базы, усовершенствование библиотеки для сохранения эффективности, надёжности и простоты использования.
  • Продолжение развития аллокатора HPA (Huge-Page Allocator) для оптимизации потребления ресурсов CPU за счёт более оптимального использования больших страниц памяти (transparent hugepage).
  • Внесение изменений для повышения эффективности работы с памятью, связанных с улучшением упаковки структур, кэширования и очистки освобождённых блоков памяти.
  • Добавление оптимизаций для архитектуры AArch64 (ARM64).


  1. Главная ссылка к новости (https://news.ycombinator.com/i...)
  2. OpenNews: Прекращена разработка библиотеки управления памятью jemalloc
  3. OpenNews: Google опубликовал новый вариант системы распределения памяти TCMalloc
  4. OpenNews: Miсrosoft открыл код системы распределения памяти mimalloc
  5. OpenNews: Менеджер распределения памяти jemalloc выпущен в виде отдельной библиотеки
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/65006-jemalloc
Ключевые слова: jemalloc, malloc, memory
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (50) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 12:49, 17/03/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • –26 +/
    Т.е. facebook в любой момент может закрыть код этой библиотеки, продолжив разработку у себя внутри.

    Любой линуксоид, фанатик GNU, который использует эту библиотеку - как саму по себе, так и в составе firefox - лицемер. Prove me wrong.

     
     
  • 2.2, Аноним (2), 12:51, 17/03/2026 [^] [^^] [^^^] [ответить]  
  • +14 +/
    Никакой проблемы нет, последняя открытая версия останется, её можно будет форкнуть.
     
     
  • 3.4, Аноним (4), 12:53, 17/03/2026 [^] [^^] [^^^] [ответить]  
  • +7 +/
    Редис и много кто уже так сделали и ничего хорошего из этого у них не вышло.
     
     
  • 4.21, Аноним (21), 14:11, 17/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > FreeBSD как был, так и остается открытым, несмотря на
    > Но у линуксоидов, фанатов GNU это вызывает

    Чувак, линуксоидам и фанатам GNU плевать на твое FreeBSD.

     
  • 4.44, Аноним (44), 17:27, 17/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > Редис и много кто уже так сделали и ничего хорошего из этого у них не вышло.

    Для редиса? Действительно ничего хорошего. А для сообщества появились независимые форки под свободными лицензиями. Желаю redis inc. скорейшего банкротства.

     
     
  • 5.71, Ванька с огорода (?), 21:41, 17/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    master-master кроме редиса кто умеет (и не так чтобы уже умер как keydb) ?!
     
     
  • 6.72, уп (?), 21:53, 17/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Ты не поверишь.

    https://www.tarantool.io/ru/doc/latest/platform/replication/replication_tutori

     
  • 5.81, Аноним (81), 12:53, 18/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Интересно, чем redis inc. не угодила анонимусу? Тем, что попыталась запретить корпорациям продавать СВОЙ продукт не отчисляя за это ни цента разработчикам?
     
  • 3.10, Аноним (1), 13:11, 17/03/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вот-вот. То есть, FreeBSD как был, так и остается открытым, несмотря на то, что Sony или кто еще чего-то там на его основе развивает.

    Но у линуксоидов, фанатов GNU это вызывает длящийся _десятилетия_ хертбатт. А поскольку среди них процент пользователей firefox (или его более свободных сборок) необычно высок, они и есть лицемеры, оправдывающие личную неприязнь к FreeBSD моральными мотивами, облаченными в высокопарные слова.

     
     
  • 4.23, Аноним (23), 14:22, 17/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    так и гну как был так и останется открытым, дальше что? линуксоиды или фряшники какието другие блобы для процов и вайфай используют? в чем лицемерие? лицемерие в том что ваша фряха нафиг никому не нужна, не тогда ни сейчас, а жпл поменял правила игры. и чтобы поменять поавила, действительно пришлось прищемить много хвостов, просто по другому нельзя, а вы дальше можете жить в страни розового пони.
     
     
  • 5.33, Аноним (-), 15:45, 17/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Я уроки чтения бесплатно не даю Перечитай еще раз, в чем лицемерие заключается ... большой текст свёрнут, показать
     
     
  • 6.37, Аноним (37), 16:25, 17/03/2026 Скрыто ботом-модератором     [к модератору]
  • +/
     
  • 2.5, Мохнонос (?), 12:53, 17/03/2026 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Так вроде бы не могут закрыть. А если и продолжат внутри себя развивать, ну что ж, предыдущий код никуда не делся - кому надо берут и дальше параллельно развивают.

    Unless otherwise specified, files in the jemalloc source distribution are
    subject to the following license:
    --------------------------------------------------------------------------------
    Copyright (C) 2002-present Jason Evans <jasone@canonware.com>.
    All rights reserved.
    Copyright (C) 2007-2012 Mozilla Foundation.  All rights reserved.
    Copyright (C) 2009-present Facebook, Inc.  All rights reserved.

    Redistribution and use in source and binary forms, with or without
    modification, are permitted provided that the following conditions are met:
    1. Redistributions of source code must retain the above copyright notice(s),
       this list of conditions and the following disclaimer.
    2. Redistributions in binary form must reproduce the above copyright notice(s),
       this list of conditions and the following disclaimer in the documentation
       and/or other materials provided with the distribution.

    THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDER(S) ''AS IS'' AND ANY EXPRESS
    OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
    MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.  IN NO
    EVENT SHALL THE COPYRIGHT HOLDER(S) BE LIABLE FOR ANY DIRECT, INDIRECT,
    INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
    LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
    PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
    LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE
    OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
    ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
    --------------------------------------------------------------------------------

     
  • 2.7, Аноним (7), 12:58, 17/03/2026 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Т.е. facebook в любой момент может закрыть код этой библиотеки,
    > продолжив разработку у себя внутри.

    Может. Но почему-то с 2009 разрабатывает и не закрыл. Это раз.
    А два - обществу все равно останется весь открытый код до момент закрытия.
    Это ничем не отличается от просто забрасывания разработки.

    > фанатик GNU

    Вот тут ты правильно подметил. Именно фанатик.
    А фанатики с логикой не дружат, для них гнутость это вера.
    И ее даже пытаться опровергать нет смысла, это как играть в шахматы с голубем.

     
  • 2.8, Аноним (8), 13:05, 17/03/2026 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Закрыть код библиотеки и продолжить разработку у себя внутри можно, сюрприз, под любой лицензией, если копирайт целиком твой. Просто берешь и меняешь лицензию. Разумеется, это не распространяется на уже выпущенный под свободными лицензиями код, который можно форкать во все стороны.

    Открытые лицензии - это про свободу, а не про рабство: от того, что я однажды выпустил код под свободной лицензией, я не обязан продолжать писать код для сообщества вечно. Но я даю сообществу свободу это делать.

     
     
  • 3.51, Аноним (51), 18:02, 17/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    >Открытые лицензии - это про свободу

    машинного кода. А я не машина, поэтому не могу сказать как им там чего. Как там они себя чувствуют. Свободными или нет.

     
  • 2.9, Аноним (9), 13:08, 17/03/2026 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > facebook в любой момент может закрыть код этой библиотеки,
    > продолжив разработку у себя внутри.

    Классическое вранье от гнутой секты.

    Продолжение разработки "у себя внутри" не закрывает код!
    Открытый код вообще практически невозможно закрыть. Только если уничтожить все копии.

    В остальном он так и останется под открытой свободной лицензией.
    А вот новый код - они имеют право писать под другой. В отличие от гнутья, которое может только запрещать.

     
     
  • 3.46, Витюшка (?), 17:38, 17/03/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А потом оказывается что никто, естественно никакую разработку кроме Facebook не вёл (а только звёздочки ставили и скачивали релизы собранной библиотеки оттуда). И весь код хранился только в их GitHub репозитории.

    Уууууупс...
    Вот "открытый код" и "самозакрылся"

     
     
  • 4.52, Аноним (52), 18:02, 17/03/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > А потом оказывается что никто, естественно никакую разработку кроме Facebook не вёл
    > (а только звёздочки ставили и скачивали релизы собранной библиотеки оттуда).

    Ага, а  1.6k forks это просто чтобы не забыть как оно называлось)

    > И весь код хранился только в их GitHub репозитории.

    И на компьютерах разработчиков удалился сам по себе.

    > Уууууупс...
    > Вот "открытый код" и "самозакрылся"

    Это как? Тебя что на гитхабе забанили?

     
  • 3.77, Аноним (77), 04:38, 18/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Вот смотри - мы оба пишем в один проект. Я форкаю и продолжаю писать в другой, более коммерчески выгодный, под другой лицензией, краем глаза посматривая в общий с тобой. Когда у меня с программистами туго, я чуть вброшу идеек в общий проект и ты напишешь мне код.  
     
  • 2.20, Аноним (21), 14:03, 17/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > Т.е. facebook в любой момент может закрыть код этой библиотеки, продолжив разработку у себя внутри.

    Ну да, как и любой другой разработчик абсолютно любой опенсорсной библиотеки. Даже ты (да, лично ты!) можешь взять jemalloc и продолжить его разработку у себя за закрытыми дверьми. Лицензия BSD не запрещает же.

    Так в чем проблема и при чем тут Facebook?

     
  • 2.22, Аноним (22), 14:20, 17/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Ты об этом даже не узнаешь.
     
  • 2.53, Аноним (51), 18:04, 17/03/2026 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Двоемыслие и ГНУ неотделимы друг от друга. Второе не смогло бы существовать без первого.
     

  • 1.13, Аноним (13), 13:27, 17/03/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    Я не понял, а где хваленный AI от ведущих разработчиков рынка? Который и от технического долга избавит, и под все современные операционные системы и оборудование допишет и адаптирует! Ведь делов-то, отдать работу самой умной и талантливой нейронке?!
     
     
  • 2.16, Sm0ke85 (ok), 13:49, 17/03/2026 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >Я не понял, а где хваленный AI от ведущих разработчиков рынка? Который и от технического долга избавит, и под все современные операционные системы и оборудование допишет и адаптирует! Ведь делов-то, отдать работу самой умной и талантливой нейронке?!

    Я б дальше пошел и предложил бы им на раст все переписать нейронкой))))

     
  • 2.32, Сталин (?), 15:45, 17/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Так вот же, дали. Новость про это, я думаю.
     
  • 2.68, Мемоним (?), 20:53, 17/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > а где хваленный AI от ведущих разработчиков рынка

    Meta не ведущий разработчик AI. Свой не дотягивает, а чужим видимо западло пользоваться.

     
  • 2.78, Аноним (77), 04:41, 18/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Так это же задача креативности нового, а не компиляция мусора.
     

  • 1.14, Аноним (14), 13:39, 17/03/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Что-то его все выкидывают в последнее время. Проекты типа RPMalloc уделываю его в пух и прах. Многие проекты переключились с jemalloc на rpmalloc или mimalloc и как по скорости аллокации, так и по общему расходу памяти они сильно выигрывают...
     
  • 1.17, aname (ok), 13:53, 17/03/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Разработка будет продолжена в форме открытого проекта, развиваемого
    > совместно с сообществом и приветствующего подключение к работе
    > сторонних участников.

    Таки нашли бесплатных

     
     
  • 2.19, Аноним (4), 14:00, 17/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Китайцев из китайских организаций!
     
     
  • 3.57, Аноним (57), 19:03, 17/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Разработают: https://opennet.ru/55394-linux
     

  • 1.26, Аноним (26), 14:50, 17/03/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    Зачем нужна какая то библиотека, что бы памятью управлять? А напрямую, без прокладок, слабо что ли?
     
     
  • 2.27, Аноним (27), 15:07, 17/03/2026 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Вы чтобы поковыряться в зубах после ужина идете в лес, рубите дерево, разделяете на щепки...
    Или просто покупаете готовые зубочистки?

    > А напрямую, без прокладок, слабо что ли?

    ... стоя в гамаке обутым в лыжи?

     
     
  • 3.38, Аноним (38), 16:25, 17/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Во всяких libc и так есть функции, которые выделяют, меняют размер, освобождают.
     
     
  • 4.42, llolik (ok), 16:38, 17/03/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Сюрприз: malloc() - это тоже аллокатор, только в составе libc. jemalloc() - это его альтернатива, как считает автор, улучшенная.
     
     
  • 5.48, Аноним (48), 17:40, 17/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > как считает автор

    Разве у автора может быть другое мнение?

     
     
  • 6.54, llolik (ok), 18:34, 17/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > Разве у автора может быть другое мнение?

    Ну, в каких-то вариантах может быть. Аллокатор в libc, на то он и стандартный, что он максимально универсальный, а значит в тех условиях, где jemalloc, например, может демонстрировать преимущество, авторы libc пошли на определённые компромиссы (производительность vs универсальность, и т.д.).

     
     
  • 7.58, _hide_ (ok), 19:17, 17/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    >>> на то он и стандартный, что он максимально универсальный

    На то он стандартный, что он максимально ПРОСТОЙ.

    А разделение аллоцированных блоков по размеру и времени жизни и т.д. -- это очень сложный процесс, который, зачастую, ломает логику работы приложений: "ну никогда раньше проблем таких не было -- это всё Ваш аллокатор виноват!" Приводят к порче данных, сложности отладки и т.д. А прирост на 1000% -- это не для программистов, это для заказчиков.

     
     
  • 8.59, llolik (ok), 19:26, 17/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Одно другого не исключает, какбы С остальным согласен ... текст свёрнут, показать
     
  • 4.66, Аноним (66), 20:04, 17/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    А как там поживает стандартный аллокатор в составе musl? До сих пор самый тopмoзной на свете?
     
     
  • 5.67, Аноним (67), 20:38, 17/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    В однопоточных задачах malloc из musl немного быстрее. В многопоточных, когда потоков больше чем ядер процессора - немного медленнее.
     
  • 2.36, Аноним (36), 16:21, 17/03/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Без каких прокладок? Это типа без libc? Ну дак и jemalloc это библа, к-е даёт тебе функцию malloc().

    Без прокладок можешь syscall'ы ядра напрямую дергать.

     
     
  • 3.45, Аноним (44), 17:32, 17/03/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Без прокладок можешь syscall'ы ядра напрямую дергать.

    Нет, дорогой, раз уж без прокладок, то давай напрямую железо дёргай. Ядро тоже прокладка.

     
     
  • 4.60, Аноним (60), 19:38, 17/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    может тогда лучше сразу квантовые электронные поля дёргать ?
     
  • 2.55, Аноним (55), 18:37, 17/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    дерзай, тебя никто не заставляет пользоватся билиотеками фреймворками и множество раз написанными велосипедами. всё, как грится, может использовать своё, только сдаётся мне, ты ни одного приложения в жизни не написал
     

  • 1.29, Аноним (29), 15:23, 17/03/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    мду уж, поэтому всякие мускулы собирали с tcmalloc, чтобы жору меньше было.
     
  • 1.47, Аноним (48), 17:39, 17/03/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    То начинают, то бросают, то возобновляют... Откуда такая нестабильность мнения?
     
  • 1.76, Lamerok (?), 02:20, 18/03/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    да встройте в него в jmalloc уже ИИ!
     
  • 1.82, Аноним83 (?), 14:57, 18/03/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Так написано как будто это не код в репозитории а дрова во дворе: полежали и сгнили сами по себе.
    А пока лежали ещё какой то долг накопился, поди плата за хранение в гите, комуналка короче.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2026 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру