forum.opennet.ru - "Доступна библиотека управления памятью jemalloc 5.3.1" (20)

"Доступна библиотека управления памятью jemalloc 5.3.1"

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"Доступна библиотека управления памятью jemalloc 5.3.1"	+/–
Сообщение от opennews (ok), 14-Апр-26, 15:06
Спустя 4 года после публикации прошлого обновления доступен релиз библиотеки управления памятью jemalloc 5.3.1, предлагающей альтернативную реализацию функций malloc, оптимизированную для снижения фрагментации и работы на многопроцессорных системах. Для решения проблем с блокировками на многоядерных системах в jemalloc для каждого ядра CPU используется своя изолированная область распределения памяти, что позволяет добиться линейной масштабируемости при росте числа потоков... Подробнее: https://www.opennet.me/opennews/art.shtml?num=65201
Ответить \| Правка \| Cообщить модератору

Оглавление

Я бы даже не стал шутить про отставить разврат - закопать стюардессу отставить, Жироватт (ok), 15:06 , 14-Апр-26, (1)

для каждого ядра CPU используется своя изолированная область распределения памят, Аноним (2), 15:34 , 14-Апр-26, (2)

Скрыто модератором, Жироватт (ok), 15:50 , 14-Апр-26, (4)
А как же общий буфер, общее адресное пространство процесса , Аноним (5), 16:37 , 14-Апр-26, (5) –1

Общее адресное пространство никуда не делось, но в многопоточной среде эффективн, Аноним (8), 16:46 , 14-Апр-26, (8)

это понятно Значит ли это что есть изолированная общая область памяти в дополне, Аноним (5), 17:01 , 14-Апр-26, (10)

Нет Адресное пространство общее Но мы внутри процесса принимаем конвенцию, что , Аноним (18), 20:18 , 14-Апр-26, (18)
Там нет и не может быть ничего изолированного Память выделенная на thread-loc, Аноним (8), 20:26 , 14-Апр-26, (19)
Нет Значит что за каждым потоком закреплён пул памяти откуда именно этот поток, Аноним83 (?), 20:56 , 14-Апр-26, (22)

Меньшая фрагментация за счет изолированных областей А внутри области такая же д, Аноним (5), 16:38 , 14-Апр-26, (6)

Не фрагментация, а lock contention , Аноним (8), 16:46 , 14-Апр-26, (9)

Прожорливый поток может залочить себе всю память , Аноним (5), 17:03 , 14-Апр-26, (11)

Нет, потоки будут бороться за доступ к shared структурам аллокатора , Аноним (8), 20:16 , 14-Апр-26, (17)

Он один из самых эффективных , Аноним (8), 16:44 , 14-Апр-26, (7) +2
Это не тут спрашивать надо, это на https engineering fb com спрашивать надо , Аноним (14), 17:50 , 14-Апр-26, (14)

Кстати, раз речь пошла о аллокаторах, что использовать вместе с musl Сабж или в, Аноним (12), 17:07 , 14-Апр-26, (12)

Вместо musl Glibc , Аноним (15), 17:51 , 14-Апр-26, (15) –1
странный вопрос, есть стандарт , который по сути есть компромис среди множества, Аноним (16), 18:38 , 14-Апр-26, (16)

А чего сложного Сделать no-op free совсем несложно Как же никто раньше не дог, Аноним (8), 20:42 , 14-Апр-26, (20)

--disable-dss - это уже давным давно было В остальном больше гонева было что оно, Аноним83 (?), 20:52 , 14-Апр-26, (21)

Сообщения [Сортировка по времени | RSS]

1. "Доступна библиотека управления памятью jemalloc 5.3.1" +/–

Сообщение от Жироватт (ok), 14-Апр-26, 15:06

Я бы даже не стал шутить про "отставить разврат - закопать стюардессу! отставить разврат - откопать стюардессу", но реально, в чем профит использовать конкретно этот аллокатор?

Ответить | Правка | Наверх | Cообщить модератору

2. "-" +/–

Сообщение от Аноним (2), 14-Апр-26, 15:34

для каждого ядра CPU используется своя изолированная область распределения памяти, что позволяет добиться линейной масштабируемости при росте числа потоков

Ответить | Правка | Наверх | Cообщить модератору

4. Скрыто модератором +/–

Сообщение от Жироватт (ok), 14-Апр-26, 15:50

Ну, в копипаст и я могу.
А реально?

Ответить | Правка | Наверх | Cообщить модератору

5. "-" –1 +/–

Сообщение от Аноним (5), 14-Апр-26, 16:37

>своя изолированная область
А как же общий буфер, общее адресное пространство процесса?

Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

8. "-" +/–

Сообщение от Аноним (8), 14-Апр-26, 16:46

Общее адресное пространство никуда не делось, но в многопоточной среде эффективнее выделять из thread-local арен.

Ответить | Правка | Наверх | Cообщить модератору

10. "-" +/–

Сообщение от Аноним (5), 14-Апр-26, 17:01

>thread-local
это понятно. Значит ли это что есть изолированная общая область памяти в дополнение к поточным?

Ответить | Правка | Наверх | Cообщить модератору

18. "-" +/–

Сообщение от Аноним (18), 14-Апр-26, 20:18

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

Ответить | Правка | Наверх | Cообщить модератору

19. "-" +/–

Сообщение от Аноним (8), 14-Апр-26, 20:26

Там нет и не может быть ничего "изолированного". Память выделенная на thread-local арене доступна всем потокам, и освобождается из любого, просто при выделении мы меньше ходим в shared state и ждём на локах.
Есть ли не привязанная к потокам арена - скорее всего да: для достаточно больших аллокаций и арены будут большие, а держать большие арены для каждого потока расточительно. Наверняка есть общая арена для больших аллокаций, она же раздаёт память в попоточные арены.

Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

22. "-" +/–

Сообщение от Аноним83 (?), 14-Апр-26, 20:56

Нет.
Значит что за каждым потоком закреплён "пул памяти" откуда именно этот поток получает куски памяти при каждом malloc()/realloc()/calloc().
Когда другой поток для такой памяти делает free() - то это в звисимости от опций и реализации может быть какой то lockless механизм который кусок памяти помещает в очередь на освобождение в пул того потока из которого но выделено. И оно там висит пока поток не потрогает апи аллокатора.
"пул памяти" - нечто виртуальное, можешь считать что это некоторая структура, вероятно со списками и массивами. Типа как экземпляр класса на крестах.
В общем вариантов много как и что можно с этим делать чтобы потоки друг другу не мешались выделяя/свобождая память.

Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

6. "-" +/–

Сообщение от Аноним (5), 14-Апр-26, 16:38

Меньшая фрагментация за счет изолированных областей? А внутри области такая же дефрагментация?

Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

9. "-" +/–

Сообщение от Аноним (8), 14-Апр-26, 16:46

> Меньшая фрагментация за счет изолированных областей?
Не фрагментация, а lock contention.

Ответить | Правка | Наверх | Cообщить модератору

11. "-" +/–

Сообщение от Аноним (5), 14-Апр-26, 17:03

Прожорливый поток может залочить себе всю память?

Ответить | Правка | Наверх | Cообщить модератору

17. "-" +/–

Сообщение от Аноним (8), 14-Апр-26, 20:16

Нет, потоки будут бороться за доступ к shared структурам аллокатора.

Ответить | Правка | Наверх | Cообщить модератору

7. "Доступна библиотека управления памятью jemalloc 5.3.1" +2 +/–

Сообщение от Аноним (8), 14-Апр-26, 16:44

> в чем профит использовать конкретно этот аллокатор?
Он один из самых эффективных.

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

14. "Доступна библиотека управления памятью jemalloc 5.3.1" +/–

Сообщение от Аноним (14), 14-Апр-26, 17:50

> в чем профит использовать конкретно этот аллокатор?
> месяц назад разработку возобновила компания Meta, применяющая jemalloc в своей инфраструктуре
Это не тут спрашивать надо, это на https://engineering.fb.com спрашивать надо.

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

12. "Доступна библиотека управления памятью jemalloc 5.3.1" +/–

Сообщение от Аноним (12), 14-Апр-26, 17:07

Кстати, раз речь пошла о аллокаторах, что использовать вместе с musl? Сабж или в интернете ещё другие нахваливают?

Ответить | Правка | Наверх | Cообщить модератору

15. "Доступна библиотека управления памятью jemalloc 5.3.1" –1 +/–

Сообщение от Аноним (15), 14-Апр-26, 17:51

> вместе с musl
* Вместо musl.
Glibc.

Ответить | Правка | Наверх | Cообщить модератору

16. "Доступна библиотека управления памятью jemalloc 5.3.1" +/–

Сообщение от Аноним (16), 14-Апр-26, 18:38

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

Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

20. "Доступна библиотека управления памятью jemalloc 5.3.1" +/–

Сообщение от Аноним (8), 14-Апр-26, 20:42

> Резервировать кусок памяти и в нем уже чтото делать, создавать обьекты и удалять не возвращая память системе, тем самым избавившись от всяких дабл-фри бай дизайн, это сложный путь
А чего сложного? Сделать no-op free() совсем несложно.
> но один раз его пройдя можно попутно решить все "проблемы"
Как же никто раньше не догадался, можно же решить все проблемы, всего-то нужно не возвращать память системе.
> в том числе с выходом за границы буфера
Double free и use after free, допустим, действительно решим, отказавшись от free. Но интересно, как это поможет от выхода за границы буфера?
> и восхваляют раст, в котором это гвоздями прибито, и никаких шагов влево вправо не дозволяется.
В rust, который ты, конечно, в глаза не видел, ничего гвоздями не прибито. Там есть и упомянутые bump аллокаторы, которые можно использовать как глобально так и по месту, и контролируемую утечку памяти можно устроить даже без unsafe, превратив любое динамически выделенное значение в &'static, а машинерии для жонглирования слайсами там столько что скоро его за перегруженность как плюсы будут ругать. Но DF/UAF на ровном месте, действительно, не сделать. Расскажи, почему это плохо.

Ответить | Правка | Наверх | Cообщить модератору

21. "Доступна библиотека управления памятью jemalloc 5.3.1" +/–

Сообщение от Аноним83 (?), 14-Апр-26, 20:52

--disable-dss - это уже давным давно было.
В остальном больше гонева было что оно там самосгнило без свежих коммитов.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2026 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "Доступна библиотека управления памятью jemalloc 5.3.1"	+/–
Сообщение от Жироватт (ok), 14-Апр-26, 15:06
Я бы даже не стал шутить про "отставить разврат - закопать стюардессу! отставить разврат - откопать стюардессу", но реально, в чем профит использовать конкретно этот аллокатор?
Ответить \| Правка \| Наверх \| Cообщить модератору


	2. "-"	+/–
	Сообщение от Аноним (2), 14-Апр-26, 15:34
	для каждого ядра CPU используется своя изолированная область распределения памяти, что позволяет добиться линейной масштабируемости при росте числа потоков
	Ответить \| Правка \| Наверх \| Cообщить модератору


	4. Скрыто модератором	+/–
	Сообщение от Жироватт (ok), 14-Апр-26, 15:50
	Ну, в копипаст и я могу. А реально?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	5. "-"	–1 +/–
	Сообщение от Аноним (5), 14-Апр-26, 16:37
	>своя изолированная область А как же общий буфер, общее адресное пространство процесса?
	Ответить \| Правка \| К родителю #2 \| Наверх \| Cообщить модератору


	8. "-"	+/–
	Сообщение от Аноним (8), 14-Апр-26, 16:46
	Общее адресное пространство никуда не делось, но в многопоточной среде эффективнее выделять из thread-local арен.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	10. "-"	+/–
	Сообщение от Аноним (5), 14-Апр-26, 17:01
	>thread-local это понятно. Значит ли это что есть изолированная общая область памяти в дополнение к поточным?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	18. "-"	+/–
	Сообщение от Аноним (18), 14-Апр-26, 20:18
	Нет. Адресное пространство общее. Но мы внутри процесса принимаем конвенцию, что для каждого потока есть выделенная область памяти, из которой он аллоцирует. Ядро и MMU об этом "ничего не знают", адресное пространство общее, просто процесс, использующий данный аллокатор, так работает со своей памятью.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	19. "-"	+/–
	Сообщение от Аноним (8), 14-Апр-26, 20:26
	Там нет и не может быть ничего "изолированного". Память выделенная на thread-local арене доступна всем потокам, и освобождается из любого, просто при выделении мы меньше ходим в shared state и ждём на локах. Есть ли не привязанная к потокам арена - скорее всего да: для достаточно больших аллокаций и арены будут большие, а держать большие арены для каждого потока расточительно. Наверняка есть общая арена для больших аллокаций, она же раздаёт память в попоточные арены.
	Ответить \| Правка \| К родителю #10 \| Наверх \| Cообщить модератору


	22. "-"	+/–
	Сообщение от Аноним83 (?), 14-Апр-26, 20:56
	Нет. Значит что за каждым потоком закреплён "пул памяти" откуда именно этот поток получает куски памяти при каждом malloc()/realloc()/calloc(). Когда другой поток для такой памяти делает free() - то это в звисимости от опций и реализации может быть какой то lockless механизм который кусок памяти помещает в очередь на освобождение в пул того потока из которого но выделено. И оно там висит пока поток не потрогает апи аллокатора. "пул памяти" - нечто виртуальное, можешь считать что это некоторая структура, вероятно со списками и массивами. Типа как экземпляр класса на крестах. В общем вариантов много как и что можно с этим делать чтобы потоки друг другу не мешались выделяя/свобождая память.
	Ответить \| Правка \| К родителю #10 \| Наверх \| Cообщить модератору


	6. "-"	+/–
	Сообщение от Аноним (5), 14-Апр-26, 16:38
	Меньшая фрагментация за счет изолированных областей? А внутри области такая же дефрагментация?
	Ответить \| Правка \| К родителю #2 \| Наверх \| Cообщить модератору


	9. "-"	+/–
	Сообщение от Аноним (8), 14-Апр-26, 16:46
	> Меньшая фрагментация за счет изолированных областей? Не фрагментация, а lock contention.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	11. "-"	+/–
	Сообщение от Аноним (5), 14-Апр-26, 17:03
	Прожорливый поток может залочить себе всю память?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	17. "-"	+/–
	Сообщение от Аноним (8), 14-Апр-26, 20:16
	Нет, потоки будут бороться за доступ к shared структурам аллокатора.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	7. "Доступна библиотека управления памятью jemalloc 5.3.1"	+2 +/–
	Сообщение от Аноним (8), 14-Апр-26, 16:44
	> в чем профит использовать конкретно этот аллокатор? Он один из самых эффективных.
	Ответить \| Правка \| К родителю #1 \| Наверх \| Cообщить модератору


	14. "Доступна библиотека управления памятью jemalloc 5.3.1"	+/–
	Сообщение от Аноним (14), 14-Апр-26, 17:50
	> в чем профит использовать конкретно этот аллокатор? > месяц назад разработку возобновила компания Meta, применяющая jemalloc в своей инфраструктуре Это не тут спрашивать надо, это на https://engineering.fb.com спрашивать надо.
	Ответить \| Правка \| К родителю #1 \| Наверх \| Cообщить модератору

12. "Доступна библиотека управления памятью jemalloc 5.3.1"	+/–
Сообщение от Аноним (12), 14-Апр-26, 17:07
Кстати, раз речь пошла о аллокаторах, что использовать вместе с musl? Сабж или в интернете ещё другие нахваливают?
Ответить \| Правка \| Наверх \| Cообщить модератору


	15. "Доступна библиотека управления памятью jemalloc 5.3.1"	–1 +/–
	Сообщение от Аноним (15), 14-Апр-26, 17:51
	> вместе с musl * Вместо musl. Glibc.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	16. "Доступна библиотека управления памятью jemalloc 5.3.1"	+/–
	Сообщение от Аноним (16), 14-Апр-26, 18:38
	странный вопрос, есть "стандарт", который по сути есть компромис среди множества архитектур и альтернатив аля glibc, то есть работает не идеально, но приемлемо, чего достаточно для большенства задач, но если вам не достаточно, то надо отталкиваться от архитектуры и особенностей проекта, можно попробовать для начала и сабж, но musl скорее про эндебер и там будет скорее хуже, а значит писать свое под свою задачу, хотя, если проект один, проще это решать на уровне проекта чтобы не плодить сущности. Резервировать кусок памяти и в нем уже чтото делать, создавать обьекты и удалять не возвращая память системе, тем самым избавившись от всяких дабл-фри бай дизайн, это сложный путь, но один раз его пройдя можно попутно решить все "проблемы", в том числе с выходом за границы буфера, юз-афтер-фри, и прочие за которые хейтят сечас си, и восхваляют раст, в котором это гвоздями прибито, и никаких шагов влево вправо не дозволяется.
	Ответить \| Правка \| К родителю #12 \| Наверх \| Cообщить модератору


	20. "Доступна библиотека управления памятью jemalloc 5.3.1"	+/–
	Сообщение от Аноним (8), 14-Апр-26, 20:42
	> Резервировать кусок памяти и в нем уже чтото делать, создавать обьекты и удалять не возвращая память системе, тем самым избавившись от всяких дабл-фри бай дизайн, это сложный путь А чего сложного? Сделать no-op free() совсем несложно. > но один раз его пройдя можно попутно решить все "проблемы" Как же никто раньше не догадался, можно же решить все проблемы, всего-то нужно не возвращать память системе. > в том числе с выходом за границы буфера Double free и use after free, допустим, действительно решим, отказавшись от free. Но интересно, как это поможет от выхода за границы буфера? > и восхваляют раст, в котором это гвоздями прибито, и никаких шагов влево вправо не дозволяется. В rust, который ты, конечно, в глаза не видел, ничего гвоздями не прибито. Там есть и упомянутые bump аллокаторы, которые можно использовать как глобально так и по месту, и контролируемую утечку памяти можно устроить даже без unsafe, превратив любое динамически выделенное значение в &'static, а машинерии для жонглирования слайсами там столько что скоро его за перегруженность как плюсы будут ругать. Но DF/UAF на ровном месте, действительно, не сделать. Расскажи, почему это плохо.
	Ответить \| Правка \| Наверх \| Cообщить модератору

21. "Доступна библиотека управления памятью jemalloc 5.3.1"	+/–
Сообщение от Аноним83 (?), 14-Апр-26, 20:52
--disable-dss - это уже давным давно было. В остальном больше гонева было что оно там самосгнило без свежих коммитов.
Ответить \| Правка \| Наверх \| Cообщить модератору