LINUX.ORG.RU

jemalloc всё

 , , ,


0

3

2 июня 2025 Jason Evans, автор аллокатора jemalloc, перевёл репозиторий в режим «только для чтения».

https://jasone.github.io/2025/06/12/jemalloc-postmortem/

Аллокатор памяти jemalloc был впервые задуман в начале 2004 года, и вот уже около 20 лет он находится в публичном использовании. Благодаря природе лицензирования программного обеспечения с открытым исходным кодом, jemalloc будет оставаться общедоступным неограниченное время. Однако активная разработка этого приложения подошла к концу. В этом посте кратко описаны этапы разработки jemalloc, каждый из которых характеризуется некоторыми успехами/неудачами, а затем даны некоторые ретроспективные комментарии.

TL;DR

jemalloc был для меня странным развлечением, поскольку я уже более 25 лет являюсь убежденным сторонником сборки мусора, а не ручного управления памятью. Лично я рад снова работать над системами со сборкой мусора, но jemalloc был чрезвычайно насыщенным проектом. Спасибо всем, кто сделал этот проект таким стоящим – и соавторам, и сторонникам, и пользователям.

★★★★★

Во-первых, не «всё», а «вероятно, достиг совершенства, и исправлять больше нечего». Во-вторых, если надо будет что-то доработать, доработают, ведь это системный аллокатор в фрибсд.

firkax ★★★★★
()
Ответ на: комментарий от firkax

тоже думаю, что его найдётся кому доработать, если вдруг что.

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

Iron_Bug ★★★★★
()

Удобный был инструмент для поиска утечек памяти, надеюсь из дистрибутивов его не выпилят.

maxcom ★★★★★
()
Ответ на: комментарий от firkax

Вот нисколько не сомневался, что GH-хейтерам не понять.

dataman ★★★★★
() автор топика
Ответ на: комментарий от Iron_Bug

просто тупое подключение джемаллока жрёт лишнюю память.

Оно жрет память пока она есть, тем самым оказывая минимальный импакт на быстродействие операций аллокации. Когда уже нету, то начинает активно дефрагментировать и мержить куски памяти. Такая у него особенность работы (по мои наблюдениям).

В любом случае, при одном и том же ворклоде, jemalloc аллоцирует меньше памяти чем tcmalloc, пускай даже с небольшим импактом на производительность. Такой себе, середнячок.

iron ★★★★★
()
Ответ на: комментарий от iron

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от firkax

Во-вторых, если надо будет что-то доработать, доработают, ведь это системный аллокатор в фрибсд.

Если Facebook, Netflix или кто-нибудь подобный занесёт денег, то доработают. Хотя, наверное, все модники уже на mimalloc переползли.

annulen ★★★★★
()
Ответ на: комментарий от annulen

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

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

Ну, очень часто ручные аллокаторы используются в сочетании со счётчиком ссылок, а там ты уже не совсем знаешь, когда память будет освобождаться. И тогда возможность включать/выключать GC в нужные моменты наоборот может дать простой в использовании контроль над задержкой.

snizovtsev ★★★★★
()
Ответ на: комментарий от snizovtsev

ну, если ты пишешь код, то ты знаешь, где у тебя выделяется и где освобождается память. единственный момент, когда ты этого не знаешь - это передача выделенной памяти в стороннюю библиотеку и там уже освобождение этой памяти - это ответственность той библиотеки. но такие случаи - это уже не рукописные пулы, а выделение памяти в куче, как правило. ну и по идее, лучше этого избегать, предоставляя интерфейсы так, чтобы тот, кто запросил память, сам же её и выделял и потом освобождал. хотя от чужих ошибок код не застрахован, да.

я никогда не соглашусь с любой автоматизацией управления памятью. это неоптимально.

Iron_Bug ★★★★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.