https://www.opennet.me/openforum/vsluhforumID3/139806.html Спустя 4 года после публикации прошлого обновления доступен релиз библиотеки управления памятью jemalloc 5.3.1, предлагающей альтернативную реализацию функций malloc, оптимизированную для снижения фрагментации и работы на многопроцессорных системах. Для решения проблем с блокировками на многоядерных системах в jemalloc для каждого ядра CPU используется своя изолированная область распределения памяти, что позволяет добиться линейной масштабируемости при росте числа потоков...<br><br>Подробнее: https://www.opennet.ru/opennews/art.shtml?num=65201<br> https://www.opennet.me/openforum/vsluhforumID3/139806.html#19 Tue, 14 Apr 2026 17:26:11 GMT Там нет и не может быть ничего "изолированного". Память выделенная на thread-local арене доступна всем потокам, и освобождается из любого, просто при выделении мы меньше ходим в shared state и ждём на локах.<br><br>Есть ли не привязанная к потокам арена - скорее всего да: для достаточно больших аллокаций и арены будут большие, а держать большие арены для каждого потока расточительно. Наверняка есть общая арена для больших аллокаций, она же раздаёт память в попоточные арены.<br> https://www.opennet.me/openforum/vsluhforumID3/139806.html#18 Tue, 14 Apr 2026 17:18:27 GMT Нет.<br><br>Адресное пространство общее. Но мы внутри процесса принимаем конвенцию, что для каждого потока есть выделенная область памяти, из которой он аллоцирует. Ядро и MMU об этом "ничего не знают", адресное пространство общее, просто процесс, использующий данный аллокатор, так работает со своей памятью.<br> https://www.opennet.me/openforum/vsluhforumID3/139806.html#17 Tue, 14 Apr 2026 17:16:46 GMT Нет, потоки будут бороться за доступ к shared структурам аллокатора.<br> https://www.opennet.me/openforum/vsluhforumID3/139806.html#16 Tue, 14 Apr 2026 15:38:28 GMT странный вопрос, есть "стандарт", который по сути есть компромис среди множества архитектур и альтернатив аля glibc, то есть работает не идеально, но приемлемо, чего достаточно для большенства задач, но если вам не достаточно, то надо отталкиваться от архитектуры и особенностей проекта, можно попробовать для начала и сабж, но musl скорее про эндебер и там будет скорее хуже, а значит писать свое под свою задачу, хотя, если проект один, проще это решать на уровне проекта чтобы не плодить сущности. Резервировать кусок памяти и в нем уже чтото делать, создавать обьекты и удалять не возвращая память системе, тем самым избавившись от всяких дабл-фри бай дизайн, это сложный путь, но один раз его пройдя можно попутно решить все "проблемы", в том числе с выходом за границы буфера, юз-афтер-фри, и прочие за которые хейтят сечас си, и восхваляют раст, в котором это гвоздями прибито, и никаких шагов влево вправо не дозволяется.<br> https://www.opennet.me/openforum/vsluhforumID3/139806.html#15 Tue, 14 Apr 2026 14:51:51 GMT &gt; вместе с musl<br><br>* Вместо musl.<br><br>Glibc.<br> https://www.opennet.me/openforum/vsluhforumID3/139806.html#14 Tue, 14 Apr 2026 14:50:49 GMT &gt; в чем профит использовать конкретно этот аллокатор?<br>&gt; месяц назад разработку возобновила компания Meta, применяющая jemalloc в своей инфраструктуре<br><br>Это не тут спрашивать надо, это на https://engineering.fb.com спрашивать надо.<br> https://www.opennet.me/openforum/vsluhforumID3/139806.html#12 Tue, 14 Apr 2026 14:07:44 GMT Кстати, раз речь пошла о аллокаторах, что использовать вместе с musl? Сабж или в интернете ещё другие нахваливают?<br> https://www.opennet.me/openforum/vsluhforumID3/139806.html#11 Tue, 14 Apr 2026 14:03:04 GMT Прожорливый поток может залочить себе всю память?<br> https://www.opennet.me/openforum/vsluhforumID3/139806.html#10 Tue, 14 Apr 2026 14:01:28 GMT &gt;thread-local<br><br>это понятно. Значит ли это что есть изолированная общая область памяти в дополнение к поточным?<br>