Комментарии 21
Как увидел заголовок, так сразу хотел написать про кастомный аллокатор, а как оказалось, вполне приличная статья.
Перед публикацией читайте статью пожалуйста, что бы не повторять по три раза подряд "если запрошенный размер маленький растягивает границу хипа через sbrk"
А что насчёт синхронизации списков блоков между потоками?
Спасибо, очень полезная информация. Писал на си около полугода, эти malloc/free прям надоели, хорошо вернулся обратно на Swift)) Писал кросс либы для android и iOS.
malloc() — это не просто «дай мне N байтов», а целая система управления памятью,
malloc() — это точно не система чего бы то ни было! malloc() — это интерфейс к системе, причем стандартный интерфейс.
Как то не хорошо начинать статью с не совсем коректных утверждений, с непродуманных формулировок.
Таки, хип, или куча?
[ Заголовок (16 байт) | Ваши 64 байта ]
Не раз попадалось в коде malloc(sizeof(int)), причем в цикле, для заполнения большого массива интов. Вот где боль...
Буквально в этом семестре в университете одно из заданий было написать malloc(), calloc(), realloc() и free(), думал, что повешусь..
Что за граница кучи? Между кучей и стэком есть третье неиспользуемое пространство?
Всегда интересовало вот что: вектор в С++ может освободить свою часть, укоротиться, но только с конца - почему нельзя освободить с начала?
del
код, стек и куча обычно не жмутся друг к другу чтобы вызывать ошибки доступа при выходе за границы - на х64 адресное пространство очень большое, никакой потребности в компактизации нет
posix стандарт не предусматривает отрезание памяти от начала, хотя мне не известно о каких-нибудь технических ограничениях почему это не могло бы быть реализовано
Всегда интересовало вот что: вектор в С++ может освободить свою часть, укоротиться, но только с конца - почему нельзя освободить с начала?
А если кто-то уже получил указатель на data, а мы таки - хопа, и сдвинули data вперёд на N байт.
Скорее всего особой потребности в подобном не было.
Более того, вектор не умеет освобождать часть себя. Обычно он запрашивает у аллокатора новый кусок памяти, переносит туда свое содержимое и отдает аллокатору старый кусок.
Хороший пост. Жаль, что нам так и не удалось узнать влияет ли sbrk() на границу хипа.
"то malloc() может сдвинуть границу (brk()) и вернуть память ОС."
Я думаю malloc не должен возвращать, речь про free
а где в my_free(*) "попытка слить с предшествующим"?
..и в примере бы сразу после my_init() - my_dump() тоже был бы к месту.
P.S. но в общем, лично для меня, статья оказалась полезной. Спасибо!)
Как malloc() и free() управляют памятью в C