Использование памяти

Все жалуются на свою память, но никто не жалуется на свой ум.
Ф.Ларошфуко

Модным поветрием последних времён стало активное использование «кучи», т.е. динамической памяти, для размещения там объектов. Даже если данные локальны и используются только внутри функции, всё равно данные зачем-то размещают в «куче», в стеке остаётся только указатель на объект. Про компоненты VCL в книгах про C++ Builder написано: конструктор работает только с оператором «new». Все экземпляры классов языка Java, или объекты, создаются с «new». Объекты кроссплатформенной библиотеки Qt тоже создаются только с помощью «new». Такое впечатление, что операция «new» теперь внесена в набор команд процессоров x86, а каждая микросхема памяти имеет заначку сверх заявленной ёмкости специально для «кучи».

void  func() {
   TOpenDialog* dlg = new TOpenDoalog(this);
   dlg -> Title = "Open a New Dialog";
   dlg -> Execute();
}

TOpenDialog*  func(this) {
   return new TOpenDoalog(this);
}

 TOpenDialog* dlg -> func(this)
 dlg -> Title = "Open a New Dialog";
 dlg -> Execute();
 TForm* ptr = new TForm();
 // ...

SomeObject value = new SomeObject();

понадобилось под Win 2003 Server x64 быстро раздавать по HTTP статические файлы — все .Net было решено ликвидировать... когда оказалось, что IIS 6 кушает около сотни мегабайт при раздаче статических файлов... создаем, например, System.List<> и работаем с коллекцией. Хорошо, удобно, красиво. Теперь представим, что такая функция вызывается очень и очень часто. В моем случае это было извлечение пользоватльских пакетов из очереди, простое шифрование и передача в сокет. Каждый экземпляр System.List<> это класс, реализующий пяток интерфейсов и имеющий два десятка виртуальных методов. Внутри него находится типизированный System.Array с нашими данными. Это ещё один класс со схожими интерфейсами и наследованием. Оба создаются в хипе, а не в стеке, что бы не рассказывали нам об умном JIT. ... При высокой нагрузке приложения отслеживается заметный рост загрузки процессора потоками GC. Замена List массивом (т.е. избавление от одного из сложных классов) заметно уменьшает нагрузку на GC. ... Вывод прост: System.Array давно перестал быть массивом... больше нет возможности создаваться в стеке.

        Да, есть некоторые неудобства работы со стеком. Компиляторам знать вовремя компиляции размеры всех объектов и их количество. Тогда они в состоянии жёстко прописать для каждого объекта смещения относительно вершины стека. Если объект имеет длину, неизвестную на момент компиляции, то как ему отвести место в стеке? Например, функции передаётся параметр, характеризующий длину локальной строки:

void  function (int N, int M) {
   char  Str1 [N];
   char  Str2 [M];
   // ...
}

void  function () {
   // ...
   while (condition)
   {   int   N = foo ();
       char  Str1 [N];
   }
   // ...
}

Стек вызовов может быть реализован как в виде специализированного стекового регистра ограниченной глубины (или даже обычного регистра адреса возврата, например в некоторых моделях PowerPC), так и в виде указателя вершины стека в оперативную память или регистровый файл процессора. При отсутствии или ограниченности стека, вложенные вызовы исключены или их количество ограничено. При необходимости бо́льшей вложенности, стек вызовов или его расширение могут быть реализовано программно.

Что ещё почитать на эту тему

• Wikipedia: Программный стек
• Управление памятью (часть I)
• Управление памятью (часть 3): Ускользающая память
• Управление памятью (часть 4): Буферная память
• Глава 10. Аппаратно-независимый уровень управления виртуальной памятью

Опубликовано: 2014.07.15, последняя правка: 2019.01.28    20:37

✅  2016/04/03 07:54, rst256          #0 

✅  2016/04/03 17:33, Автор сайта          #1 

Принцип стека бесспорно входит в 10-ку основных методов работы с памятью

после получения блока данных их нужно засунуть во внешнюю функцию, вы знаете, когда можно будет освободить данный блок?

определить, где и насколько долго будут нужны возвращаемые функцией данные, есть очень нетривиальная задача.

Ах да чуть не забыл, есть вероятность, что данный стек используется несколькими потоками, нужны блокировки, семафоры и проч. А то как же без реентарности то, без реентарности сейчас никуда.

• При многопоточном программировании, когда функция вместе со своим стеком умирает раньше, чем поток, который использует данные.
• Функция должна получать, хранить и освобождать данные, при этом порядок освобождения памяти произволен, т.е. нарушен принцип LIFO.

✅  2016/04/11 18:18, rst256          #2 

Вообще-то основных способов три: статическая память, динамическая («куча») и стек. Всё остальное — от лукавого.

Вполне тривиально для однопоточного программирования.

f1(...){
char *s = f2(...);
some_func(s);
}

static char *S0 = NULL;
some_func(char s*){ S0=s; }
char * some_func2(){ return S0; }

void  func() {
   TOpenDialog* dlg = new TOpenDoalog(this);
   dlg -> Title = "Open a New Dialog";
   dlg -> Execute();
}

✅  2016/04/13 16:01, Автор сайта          #3 

Я могу статически выделить память под стек? А из кучи?

как на такие игры с esp отреагируют эвристика антивирусной программы?

любой код, использующий GUI, будет многопоточным.

dlg будет жить гораздо дольше, чем вызов func

✅  2016/08/06 19:54, rst256          #4 

Интересные вопросы Вы задаёте. Я даже не задумывался об этом. Антивирус на моём компьютере молчал всё это время.

В DOS не было многопоточности, но были прерывания.

Прерывания — это очень просто: либо работает обычный код, либо код, обрабатывающий прерывание, но вместе — никогда. Поэтому там не нужны были блокировки, мьютексы и т.д.

Судя по коду, который вы привели, указатель на память dlg умрёт вместе с функций. Ведь функция имеет тип void (dlg не возвращается), переданный ей список параметров пуст (dlg не сохранятся через переданный указатель), код не пишет в статическую память (dlg не сохраняется вовне, в глобальной переменной). Следовательно, dlg умрёт вместе с родительской функций. А вот память, на которую ссылается dlg, останется жить. Имеет место быть классическая «утечка памяти»: выделенная память не уничтожается вместе с указателем. Это тот случай, который хороший язык программирования должен предотвратить: надо либо передать dlg куда-то вовне, либо вызвать delete.

Добавить свой отзыв

Написать автору можно на электронную почту
mail(аt)compiler.su