| 1.1, Жироватт (ok), 15:06, 14/04/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Я бы даже не стал шутить про "отставить разврат - закопать стюардессу! отставить разврат - откопать стюардессу", но реально, в чем профит использовать конкретно этот аллокатор?
| | |
| |
| 2.2, Аноним (2), 15:34, 14/04/2026 [^] [^^] [^^^] [ответить]
| +/– |
для каждого ядра CPU используется своя изолированная область распределения памяти, что позволяет добиться линейной масштабируемости при росте числа потоков
| | |
| |
| 3.5, Аноним (5), 16:37, 14/04/2026 [^] [^^] [^^^] [ответить]
| –2 +/– | |
>своя изолированная область
А как же общий буфер, общее адресное пространство процесса?
| | |
| |
| 4.8, Аноним (8), 16:46, 14/04/2026 [^] [^^] [^^^] [ответить]
| +/– |
Общее адресное пространство никуда не делось, но в многопоточной среде эффективнее выделять из thread-local арен.
| | |
| |
| 5.10, Аноним (5), 17:01, 14/04/2026 [^] [^^] [^^^] [ответить]
| +/– | |
>thread-local
это понятно. Значит ли это что есть изолированная общая область памяти в дополнение к поточным?
| | |
| |
| 6.18, Аноним (18), 20:18, 14/04/2026 [^] [^^] [^^^] [ответить]
| +/– | |
Нет.
Адресное пространство общее. Но мы внутри процесса принимаем конвенцию, что для каждого потока есть выделенная область памяти, из которой он аллоцирует. Ядро и MMU об этом "ничего не знают", адресное пространство общее, просто процесс, использующий данный аллокатор, так работает со своей памятью.
| | |
| 6.19, Аноним (8), 20:26, 14/04/2026 [^] [^^] [^^^] [ответить]
| +/– | |
Там нет и не может быть ничего "изолированного". Память выделенная на thread-local арене доступна всем потокам, и освобождается из любого, просто при выделении мы меньше ходим в shared state и ждём на локах.
Есть ли не привязанная к потокам арена - скорее всего да: для достаточно больших аллокаций и арены будут большие, а держать большие арены для каждого потока расточительно. Наверняка есть общая арена для больших аллокаций, она же раздаёт память в попоточные арены.
| | |
| 6.22, Аноним83 (?), 20:56, 14/04/2026 [^] [^^] [^^^] [ответить]
| +/– | |
Нет.
Значит что за каждым потоком закреплён "пул памяти" откуда именно этот поток получает куски памяти при каждом malloc()/realloc()/calloc().
Когда другой поток для такой памяти делает free() - то это в звисимости от опций и реализации может быть какой то lockless механизм который кусок памяти помещает в очередь на освобождение в пул того потока из которого но выделено. И оно там висит пока поток не потрогает апи аллокатора.
"пул памяти" - нечто виртуальное, можешь считать что это некоторая структура, вероятно со списками и массивами. Типа как экземпляр класса на крестах.
В общем вариантов много как и что можно с этим делать чтобы потоки друг другу не мешались выделяя/свобождая память.
| | |
| |
| 7.24, Аноним (5), 23:26, 14/04/2026 [^] [^^] [^^^] [ответить]
| +/– |
Понятно. При создание потока ему передается указатель на структуру, через которую управляющий jemalloc выделил ему память (вроде this). Для прозрачности его теневым образом можно передавать функциям *alloc из этого потока. Владельцем структуры, отвечающей за память потока, остается поток "родивший" этот поток. Использующий структуру может только пометить кусок на удаление (или автоматически помечается на выходе). В асме я встречал инструкции работающие с сегментными регистрами на x64 (это и защищает приватную память потока).
Для общей памяти должны быть, тогда, "статические" функции аллоцирования.
| | |
| |
| |
| 9.28, Аноним (5), 23:36, 14/04/2026 [^] [^^] [^^^] [ответить] | +/– | В асме встречаются обращения к ячейкам памяти через сегментный регистр на x64 И... текст свёрнут, показать | | |
| 9.29, Аноним (5), 23:39, 14/04/2026 [^] [^^] [^^^] [ответить] | +/– | Я дам этому потоку смещенную базу и он будет наращивать потребление относительно... текст свёрнут, показать | | |
|
| 8.27, Аноним (5), 23:30, 14/04/2026 [^] [^^] [^^^] [ответить] | +/– | Тогда суть в том что упор делается на поточный пул и разнобой общей памяти от по... текст свёрнут, показать | | |
|
| 7.31, Аноним (5), 00:01, 15/04/2026 [^] [^^] [^^^] [ответить]
| +/– | |
>за каждым потоком закреплён "пул памяти" откуда именно этот поток получает куски памяти при каждом malloc()/realloc()/calloc().
malloc(xxx) вызывается на самом деле malloc(this_thread,xxx). В дальнейшем менеджер предложит потоку указатель смещенный относительно первого на размер предыдущего (ххх). Легко освободить разом всё память, предоставленную потоку и освободить большой кусок памяти а не "черезполосицу" с другими потоками.
| | |
|
|
|
|
| 3.6, Аноним (5), 16:38, 14/04/2026 [^] [^^] [^^^] [ответить]
| +/– |
Меньшая фрагментация за счет изолированных областей? А внутри области такая же дефрагментация?
| | |
| |
| 4.9, Аноним (8), 16:46, 14/04/2026 [^] [^^] [^^^] [ответить]
| +/– | |
> Меньшая фрагментация за счет изолированных областей?
Не фрагментация, а lock contention.
| | |
| |
| |
| 6.17, Аноним (8), 20:16, 14/04/2026 [^] [^^] [^^^] [ответить]
| +/– |
Нет, потоки будут бороться за доступ к shared структурам аллокатора.
| | |
|
|
|
|
| 2.7, Аноним (8), 16:44, 14/04/2026 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> в чем профит использовать конкретно этот аллокатор?
Он один из самых эффективных.
| | |
| 2.14, Аноним (14), 17:50, 14/04/2026 [^] [^^] [^^^] [ответить]
| +/– |
> в чем профит использовать конкретно этот аллокатор?
> месяц назад разработку возобновила компания Meta, применяющая jemalloc в своей инфраструктуре
Это не тут спрашивать надо, это на https://engineering.fb.com спрашивать надо.
| | |
|
| 1.12, Аноним (12), 17:07, 14/04/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Кстати, раз речь пошла о аллокаторах, что использовать вместе с musl? Сабж или в интернете ещё другие нахваливают?
| | |
| |
| 2.16, Аноним (16), 18:38, 14/04/2026 [^] [^^] [^^^] [ответить]
| –1 +/– |
странный вопрос, есть "стандарт", который по сути есть компромис среди множества архитектур и альтернатив аля glibc, то есть работает не идеально, но приемлемо, чего достаточно для большенства задач, но если вам не достаточно, то надо отталкиваться от архитектуры и особенностей проекта, можно попробовать для начала и сабж, но musl скорее про эндебер и там будет скорее хуже, а значит писать свое под свою задачу, хотя, если проект один, проще это решать на уровне проекта чтобы не плодить сущности. Резервировать кусок памяти и в нем уже чтото делать, создавать обьекты и удалять не возвращая память системе, тем самым избавившись от всяких дабл-фри бай дизайн, это сложный путь, но один раз его пройдя можно попутно решить все "проблемы", в том числе с выходом за границы буфера, юз-афтер-фри, и прочие за которые хейтят сечас си, и восхваляют раст, в котором это гвоздями прибито, и никаких шагов влево вправо не дозволяется.
| | |
| |
| 3.20, Аноним (8), 20:42, 14/04/2026 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Резервировать кусок памяти и в нем уже чтото делать, создавать обьекты и удалять не возвращая память системе, тем самым избавившись от всяких дабл-фри бай дизайн, это сложный путь
А чего сложного? Сделать no-op free() совсем несложно.
> но один раз его пройдя можно попутно решить все "проблемы"
Как же никто раньше не догадался, можно же решить все проблемы, всего-то нужно не возвращать память системе.
> в том числе с выходом за границы буфера
Double free и use after free, допустим, действительно решим, отказавшись от free. Но интересно, как это поможет от выхода за границы буфера?
> и восхваляют раст, в котором это гвоздями прибито, и никаких шагов влево вправо не дозволяется.
В rust, который ты, конечно, в глаза не видел, ничего гвоздями не прибито. Там есть и упомянутые bump аллокаторы, которые можно использовать как глобально так и по месту, и контролируемую утечку памяти можно устроить даже без unsafe, превратив любое динамически выделенное значение в &'static, а машинерии для жонглирования слайсами там столько что скоро его за перегруженность как плюсы будут ругать. Но DF/UAF на ровном месте, действительно, не сделать. Расскажи, почему это плохо.
| | |
|
|
| 1.21, Аноним83 (?), 20:52, 14/04/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
--disable-dss - это уже давным давно было.
В остальном больше гонева было что оно там самосгнило без свежих коммитов.
| | |
|
