LINUX.ORG.RU

Implementation-defined. Проще всего - разместить счетчик перед первым байтом выделенной памяти.

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

Этим ядро занимается, так что malloc'у знать ничего не положено.

На самом деле даже не ядро но где-то на kernel.org есть специальный сервис, которых хранит каталог всех выделенных блоков памяти. Так надежнее.

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

Угу, этот сервис называется Git. Не зря же его Линус сотоварищи писали?

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

> > Этим ядро занимается, так что malloc'у знать ничего не положено.

Разве у libc нету своей прослойки?

даже если забыть о прослойках в libc и kernel.org, остается вопрос что делает аргумент size в вызове munmap.

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

>даже если забыть о прослойках в libc и kernel.org, остается вопрос что делает аргумент size в вызове munmap.

он находит случайный кусок памяти с совпадающим размером и грубо удаляет его!

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

даже если забыть о прослойках в libc и kernel.org, остается вопрос что делает аргумент size в вызове munmap.

Семантика у них чуток разная, только и всего. malloc(3) не умеет 'частично' освободить память, только весь выделенный ранее блок целиком. munmap(2) может.

bibi
()

>где malloc хранит информацию о размере выледенной памяти?

Нигде не хранит. Просто - помнит (как слакварщики «помнят» наиусть все зависимости в своей «системе»)

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

Все известные мне имплементации хранят перед собственно блоком. Посмотри dlmalloc, если интересно. Большая часть аллокаторов из него сделана.

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

Все известные мне имплементации хранят перед собственно блоком. Посмотри dlmalloc, если интересно. Большая часть аллокаторов из него сделана.

Мне это не интересно. А вот что ядро занимается работой malloc'а - вот это хотелось бы более детально послушать :)

mv ★★★★★
()

а что линуксоидов зобанили в исходниках своего glib? :]

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

Мне это не интересно. А вот что ядро занимается работой malloc'а - вот это хотелось бы более детально послушать :)

Блин, я не тебе отвечал, просто тыкнул ближайший «ответить на это сообщение». Что ты и так знаешь, как работают аллокаторы, я не сомневаюсь :)

ratatosk
()
Ответ на: комментарий от mv

А я так глубоко и не копал - работает, ну и ладно. Я всегда думал, что при выделении памяти при помощи malloc/calloc ядро предоставляет первый свободный блок памяти подходящего размера, и само же «для себя» делает пометку, что этот блок выделен такому-то процессу. Если процесс дохнет, не успев сделать free, ядро память освобождает.

А по-вашему выходит, что каждый раз, когда я в программе, динамически выделяющей память, нажму ctrl+C до free, у меня будет происходить утечка памяти... Фигня какая-то получается.

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от Eddy_Em

А по-вашему выходит, что каждый раз, когда я в программе, динамически выделяющей память, нажму ctrl+C до free, у меня будет происходить утечка памяти... Фигня какая-то получается.

По-нашему получается, что ядро по запросу процесса может добавить в адресное пространство ещё страничек памяти (обычно, гранулярностью по 4096 байт, но бывает и больше, и меньше), либо отрезать их. Как там процесс организует работу с памятью в рамках своего личного адресного пространство (АП) - ядро не волнует. Соответственно, в программах используется какой-либо менеджер (аллокатор) для управления пулом доступной памяти. Такой менеджер может выделить программе (заметь, из её же АП) блок памяти любого размера, от 1 байта до практического лимита, и пометит у себя в маленькой чёрной книжечке, что, де, вот по такому адресу у нас выделено столько-то байт. Детали реализации книжечки, т.е. как менеджер хранит информацию о выделенной и свободной памяти, нигде не оговариваются.

У ядра есть примерно такой же механизм, ибо оно должно знать, где и сколько есть физической памяти, кому она выделена, а также как «сшито» виртуальное АП разных процессов. Это примерно в 100500 раз сложнее, чем банальный malloc/free в юзерспейсе.

mv ★★★★★
()

Погуглите уже на тему организации хипа. Надеюсь нет бана?

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

Мне это не интересно. А вот что ядро занимается работой malloc'а - вот это хотелось бы более детально послушать :)

Ну очепятался человек, че накинулись то? Со всеми бывает.

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

Ну очепятался человек, че накинулись то? Со всеми бывает.

Нет, он заблуждался. Просветительская работа проведена.

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

> Все известные мне имплементации хранят перед собственно блоком.

Значит не все ты видел. Большинство реализаций создают отдельные блоки на каждый из малых размеров, и, соответственно, на выделение 100 раз по int они не будут тратить 200*sizeof(int). То есть, информация о размере выделенного куска вычисляется из его адреса.

anonymous
()
Ответ на: комментарий от Eddy_Em

> Я всегда думал, что при выделении памяти при помощи malloc/calloc ядро предоставляет первый свободный блок памяти подходящего размера, и само же «для себя» делает пометку, что этот блок выделен такому-то процессу.

Ядро ничем таким не занимается. Ядро обслуживает вызов mmap(), которым malloc из libc себе отгрызает сразу большие куски, внутри которых уже и резвится.

anonymous
()

Есть системный вызов sysbrk, которые устанавливает размер heap. Все просто.

Менеджер памяти в библиотеке С хранит размер или в отдельном блоке, или в структуре ПЕРЕД адресом, который возвращает malloc. Или он хранит перед этим адресом адрес, где он хранит размер. И конечно может быть еще какая нибудь реализация, но все в этом духе. Можно пощупать, прочитав данные перед ним. Ничего плохого не случится скорее всего, segfault случается при чтении из адресов, которых нету в адресном пространстве процессе. Адресное пространство процесса состоит из нескольких частей (в Intel по крайней мере)

- Сегмент кода (из вашего бинарника)

- Инициализированные данные (в вашем бинарнике хранятся)

- Неинициализированный данные (в бинаринке только размер, выделятся системой при запуске)

- Куча (задается с помощью sysbrk, растет вверх)

- Стек (задается уменьшением esp, растет вниз)

Поправьте если что не так.

Вызовы malloc/free размещают кусочками ваши указатели в куче, меняя ее размер по мере надобности.

vertexua ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.