Динамические объекты создаются и уничтожаются в памяти «кучи» (heap) с помощью доступных программисту операторов new/delete. В порядке самообразования по С++ хотел бы уточнить следующие скрытые от нас подробности:
1. Действия по динамическому размещению полей данных объекта в куче выполняет прикладная программа или операционная система?
2. Если за размещение в куче ответственна ОС, то все ли из ОС поддерживают динамические объекты (и в частности для встраиваемых систем)? И как в таком случае обслуживается одновременная работа нескольких активных на данный момент программ с общей кучей, или у каждой программы своя куча?
3. Если полей данных у конкретного объекта много, то его данные размещаются в памяти непрерывно или с разрывами (перескоками), в зависимости от текущего состояния кучи ?
4. Что можно почитать на эту тему по-подробней?

Хорошие вопросы... Правда немного из серии "почему солнце светит?"

Функции управления кучей (malloc/free) и более модные new/delete реализованы в библиотеках. Они пользуются памятью, которые просят у ОС, если такая есть вообще. В Ц++ new/delete можно довольно легко переопределить и сделать свои аллокаторы.

Память выделяемая new/malloc всегда непрерывная (с точки зрения ее пользователя).
Читать начиная со Страуструпа.. Ну, или Кернигана с Ричи.

Это занятие ни к чему хорошему не приведет.
Кучи слишком сложная тема чтобы пользоваться старыми книгами.

Первое что надо знать - это то что кучи делают все. И ОС, и компилятор, и сами прикладные программы их могут переопределять.

Т.е. в одной среде разработки вы можете иметь выбор нескольких движков куч.
Например в RAD Studio под Windows есть старый движок кучи, новый движок и движок который они наследуют из API Windows.

Для встраиваемых систем еще все хуже и запутанней.
Во первых, стандартное управление кучей есть в библиотеках компилятора.
Но даже так там есть механизм подстройки когда самые низкоуровневые функции движка кучи программист должен подстроить сам.
Во всех RTOS тоже есть свои механизмы кучи поскольку они не надеются на штатную подстройку компилятора.
Во FreeRTOS аж три движка кучи на выбор.
Для RTOS куча является очень критичным моментом поскольку надо обеспечить фиксированное время выполнения ее функций и безопасный доступ при многозадачности, часто еще и таймаут доступа делают.
Поэтому стандартные библиотечные кучи не используют, а перенаправляют new/delete на свои функции.
Однако при старте программы движок RTOS еще не работает, поэтому конструкторы объектов могут напороться еще на библиотечные функции.
Короче в этой теме кругом грабли.

Читать надо мануал на конкретный компилятор и ОС. Классики не помогут.

А дальше можно изучить мысли товарища Александреску по этому поводу
https://erdani.com/publications/cuj-2005-12.pdf
И более свежий, интересный видос
https://youtu.be/LIb3L4vKZ7U

Спасибо за разъяснения.
Пока еще не все понятно, но мнение мое по этому вопросу складывается такое.
Память под «кучу» упорядочивается и представляется, как бы в виде большой кассеты с группами коробочек разных величин. При создании объекта, ему выделяется нужная по размеру коробочка, а если они закончились, то большая из ближайшей группы. Если коробочек уже не хватает, то на основе статистики о требуемых размерах памяти создают следующую кассету. Для кассеты ведется текущий реестр учета свободных и занятых коробок, по которому и выделяется указатель на свободную память. То есть, кучи, и тем более «мало-кучи» в нашем понимании, как токовой нет, а все как бы строго упорядочено и физическая память под один динамический объект все же непрерывна, а не размазана с разрывами по её разным областям.
Поправьте, если понял не так…

Это всего лишь одна из очень многих стратегий. На начальном этапе вы можете об этом не задумываться. Вы просто можете пока считать, что есть некая "куча" из которой вам выделят непрерывный кусок запрошенного вами размера. Или не выделят, если непрерывного куска запрошенного размера в данный момент в куче нет.
Это вам сказали в самом первом ответе. Как же может быть иначе? Система же не знает, что вы там хотите разместить. Но вы можете некоторые данные своего объекта хранить отдельно, в дополнительно запрашиваемой памяти. Запрашивать ее можно в конструкторе, а освобождать - в деструкторе.

Это вы описали не кучу, а Partitions.
В экстремально реалтаймных ситуациях, память выделяемая из Partitions так и остается в виде связных цепочек блоков, т.е. не представляют собой непрерывных областей.

А вот в какой RTOS вы нашли пункт о сборе статистики у Partitions уже интересней. Не поделитесь ссылкой?

Команд new/delete мне в работе хватает без вопросов. Просто любопытно знать о «кучах» больше...

А какие еще есть стратегии управления кучей? Где об этом почитать?
Освободившаяся память после удаления объекта имеет конечный размер. А как ее заполняют вновь, только ли объектами не большими по размеру от предыдущего? Или все-таки без разрывов никак?

Статистика числа объектов и их размер упомянуты в статье из сообщения от sigmaN.

http://peguser.narod.ru/translations/files/tlsf.pdf

Тут


Зависит от реализации. Вменяемому менеджеру памяти ничего не мешает объединить освободившийся участок с соседними свободными.

В общем случае - это не так.
Никто не мешает системе, в распоряжении которой есть MMU, сделать маппирование одного сплошного диапазона логических адресов (блока памяти выделяемого пользовательскому ПО) на несколько несмежных диапазонов физических адресов.
А вот делает-ли такое какая-то конкретная ОС или нет - не знаю.


Вменяемый может даже несмежные физические блоки объединить. Воспользовавшись услугами MMU.

Да, но на каком уровне это MMU задействуется?
Думаю что штатные менеджеры, скажем на PC, не привлекают MMU. Это слишком затратно по времени.
MMU могут привлечь для всего блока памяти кучи, но не для выделения и объединения фрагментов.

Ну - не очень затратно. Например: можно реализовать это в обработчике void * недостаточно_памяти(ulong требуемый_размер)
Такой обработчик может собрать имеющиеся разрозненные свободные блоки и в специально выделенном диапазоне лог. адресов построить карту перемаппирования, сохранить себе полученный лог.адрес и вернуть его. В delete надо будет конечно сделать проверку на предмет освобождения такого блока.
В некоторых случаях думаю важнее всё-таки получить память, пусть и чуть медленнее. Но медленее будет идти работа только с этими блоками, с обычными блоками - примерно так же.
Не говорю что это где-то так реализовано. Просто это возможно.

Так никто не спорит, только надо будет для этого инвалидировать все многометровые кэши, запретить прерывания, исключения и т.д.

Точнее 5. ))
heap_1 - the very simplest, does not permit memory to be freed
• heap_2 - permits memory to be freed, but not does coalescence adjacent free blocks.
• heap_3 - simply wraps the standard malloc() and free() for thread safety
• heap_4 - coalescences adjacent free blocks to avoid fragmentation. Includes absolute address placement option
• heap_5 - as per heap_4, with the ability to span the heap across multiple non-adjacent memory areas