Как правильно освобождать память в данной ситуации?

Имею стандартный код типа

Память смотрю через SM04.

Когда выполняемая транзакция возвращается на экран выбора, то (начиная со второго прогона) сумма памяти стабильна.
Однако если смотреть в момент вывода ALV, то каждый раз по чуть чуть добавляется (второй прогон относительно первого много дабавляет, дальше уже по чуть-чуть).

а сотый экран откуда вызывается?
из start-of-selection/end-of-selection?

Правильно освобождать через перезапуск транзакции(leave to) или отчёта(SUBMIT).
В остальном - сомнительная борьба с полу-мифическим сборщиком памяти и механизмами её использования, без ощутимых бонусов по сравнению с затраченным на борьбу временем.

Да CALL SCREEN 100. в start-of-selection.
Да, конечно утечки там небольшие, порядка 3Кбайт и совершенно не критичные. Но вопрос не в этом. Мне в принципе не нравится, что они есть. Я считаю, что это непорядок. И почему бы это не поправить, если есть такая возможность? Предполагаю, что итоговое решение будет эквивалентно по затратам на программирование (за однократным вычетом поиска этого решения). Или Вы хотите сказать, что в САПе настолько небрежно реализовали ООП, что такие утечки - неустранимы?

Память в ABAP освобождается при завершении внутренней сессии. sy-uname правильно написал. Зачем стрелять из пушки по воробьям, если обычным делом является ограничение памяти для сеанса пользователя 4ГБ?
Лучше оптимизировать работу с памятью сервера приложений.

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

Всегда лучше делать проще - на мой взгляд REUSE* покрывает 99% всех хотелок.

Мне тоже не нравится, я тоже заморачивался этим несколько лет назад, пытался создавать и удалять объекты контэйнера и грида. Правда тогда деструкторы классов еще не работали в принципе - SAP изначально сделали ставку на сборщика мусора. Тогда я напоролся на неразрешимую проблему - циклическую ссылку, контейнер ссылается на грид, а грид на контейнер, поэтому САПа принципиально не могла удалить объекты из памяти, пока активна программа. Может что то и изменилось с тех пор, но заморачиваться я перестал. Зачем против ветра... ?

p.s.
Вы случаем раньше не писали на Borland Pascal ?

То есть все согласны с тем, что ООП в АБАПе реализована небрежно? И никого это не волнует? Конечно любой конкретный юзер задолбается достигать лимита оперативной памяти через многократный возврат на экран выбора. Но я лично считаю, что такая реализация - полное безобразие. Даже странно, что они реализовали деструкторы при таком отношении...

Ещё последний вопрос ко всем: мнения насчёт утечек - ваш личный опыт или есть какой-нибудь на более-менее официальный источник от SAP, в котором подтверждается такая небрежность реализации?

P.S. GRID я тоже пробовал освобождать - утечки остаются.

P.P.S. И да, я действительно раньше много писал на Borland Pascal. А ещё раньше писал на других языках и меня конечно в своё время учили экономить память. Так или иначе, это моё личное предпочтение - обращать внимание на такие вещи. Если кому-то это неинтересно - ради бога, пишите как хотите. Пока система справляется с вашим кодом - никакх проблем.

VKB, вы страдаете ерундой. Без обид, но:
1. Реализация ООП, как парадигмы написания программ, не имеет никакого отношения к утечкам памяти
2. Кроме Pascal существуют другие языки программирования. В которых работа с памятью реализована несколько иначе.

Идите с Java или С# воюйте, расскажите какое небрежное у них ООП.

А кто сказал что это утечки??? На основании чего Вы решили что имеют место утечки, а не просто особенность работы менеджера памяти и внутренних объектов???
Утечка была бы если бы память уходила после закрытия сессии, а в пределах сессии её использование не регламентировано чётко и однозначно.
И в любом случае, если Вы считаете "утечку" проблемой, ни чего не мешает Вам выставить сообщение в поддержку SAP.

А личный опыт говорит что в 99,999 % пользователь выходит из транзакции, тем самым полностью освобождая память внутренней сессии.

Более того, если его сессия залезет в heap memory, то появится сообщение, что нужно обязательно выйти из транзакции

Обсуждение пошло в сторону от того, ради чего я его затеял. Почему-то все обиделись на мои слова о небрежной реализации ООП в АБАПе. Я же собственно не ради флейма поднял эту тему. Просто попутно высказал своё мнение о таких реализациях языков (и не надо приводить в примеры Java и C#, я сам могу привести в пример ALGOL68, кстати прародитель паскаля, в котором уже была заложена концепция сборки мусора). Мне приходилось видеть великое множество неэффективных программ, в том числе и на паскале. При программировании всегда есть выбор между скоростью разработки и оптимизацией выполнения. Бывает, что одно важнее, бывает, что другое. А бывает, что программист не знает как писать оптимальный код, хотя по трудозатратам это несущественно. Я ни в коей мере не считаю себя крутым абапером (иначе бы не задавал таких вопросов), но все, кто занимается решением проблем производительности SAP отмечают как один из основных факторов - пресловутые Z-отчёты...

Поэтому если уважаемые гуру считают, что это фича АБАПа и с нею ничего поделать нельзя - ради бога. По большому счёту я всего лишь интересовался как мне минимизировать влияние этой замечательной фичи, а остальное всё - лирика. Затевать холивары на эту тему контрпродуктивно.

В качестве сухого остатка по сути темы имеем:

1. Вопрос от John Doe о том почему я не освобождаю так же и GRID (который можно трактовать как +1 к моему вопросу, ведь я сам спрашиваю КАК надо освобождать объекты).

2. Рекомендацию использовать 'REUSE...'. Но всё-таки 1% даже сам John Doe оставляет на случаи, когда лучше использовать объекты. Поэтому как минимум эта рекомендация носит ограниченый характер. Хотя это и лучше чем ничего, но выглядит примерно как если в ответ на вопрос "Как решать уравнения?" Вам бы ответили: "Численными методами. Точные аналитические решения нужны только в 1% случаев".

3. Рекомендацию sy-uname перезапускать транзакцию или отчёт. Но мой пример - лишь пример. Возможно в другом случае потребуется реализовать более сложную логику, когда объекты могут создаваться динамически в заранее неизвестном количестве и прерывать работу транзакции нельзя.

Остальное сводится к тому, что не надо об этом париться, пиши как попало, в конце сессии всё уничтожится.

Конкретно по этому примеру помимо уже поднятого вопроса о об освобождении грида я надялся, что кто-то прокомментирует event_receiver . В примере он создавался тоже внутри PBO-модуля экрана. Я вынес его создание в секцию инициализации. Меня смущает то, что у него нет деструктора и то, что в PBO выполняется регистрация события каждый раз. Возможно следует где-то вызывать какую-нибудь обратную процедуру? Или всё это автоматически уничтожается после освобождения контейнера?

Пресловутыми становятся Z-отчёты в первую очередь из-за не оптимальных SELEC-ов, а во вторую из-за не ограниченных SELECT-ов и выборок данных как таковых. Это основные места потери производительности. Наряду с обработкой внутренних таблиц.

По поводу правильности написания кода - есть классический пакет SLIS, содержащий примеры по работе с ALV.

И опять - почему Вы решили что т.н. "утечка памяти" вызвана именно Вашим кодом, а не внутренними механизмами SAP?

VKB, да никто не обиделся, что вы. Вы, просто, не там ищете точку приложения своих усилий.
В SAP системный уровень скрыт от программиста. Ему доступен только прикладной. Т.е. пытаться воевать с ветряными мельницами - суть пустая трата времени. Не освободилась память после уничтожения экземпляра объекта - значит и не освободилась. Повлиять на данный процесс вы никак не сможете.
Лучше оптимизировать логику работы программы, сокращать ненужные действия, лишние обращения к БД и т.д.
Это куда важнее

Причём здесь вообще селекты? Нет, я понимаю, что селекты - это важная вещь, а их оптимизация даёт значительный эффект. Если бы у меня была конкретная задача и я спрашивал как мне оптимизировать её выполнение, то безусловно были бы уместны и советы насчёт селектов и насчёт "REUSE...".

Но у меня чисто теоретический вопрос именно про работу с классами. И я даже соглашусь, что это менее важный вопрос, чем селекты, но тем не менее он есть. Те, кто просто переписывает куски кода из примеров, не пытаясь вникнуть почему там так написано, свою позицию обозначили уже достаточно. Я её принял к сведению, спасибо. Прошу помощи у тех, кто вникал в этот вопрос.

Я конечно тоже свою программу "списывал" с АБАПовских примеров из SLIS. Если бы мне было всё понятно из этих примеров, я бы тут ничего не спрашивал.

Давайте возмём один из самых коротких примеров - BCALV_GRID_DEMO (версия 700). Там нет экрана выбора, но зато есть примечательный кусочекВ данном случае понятно, что "снявши голову по волосам не плачут", поэтому можно очистные конструкции закомментировать. Но зачем их тут оставили? Я предполагаю, чтобы продемонстрировать, что вообще говоря, если бы не LEAVE PROGRAM, то их следовало бы вызвать. При этом для объекта GRID1 такой конструкции нет. Что может означать, что грид освобождать в любом случае не нужно, хотя класс CL_GUI_ALV_GRID имеет деструктор FREE. Кусочек кода метода FREE у класса контейнера подтверждает это: Видно, что грид будет автоматически освобождён при освобождении контейнера, ибо при создании указывается, что он помещается внутрь контейнера. Parazit указывал, что с освобождением грида и контейнера у него были сложности. Я таких сложностей не наблюдал. Если освобождать грид до освобождения контейнера, то всё работает нормально. А если после, то система ругается, что объекта не существует. Что подтверждает освобождние вложеных объектов при освобождении контейнера.

В примере BCALV_GRID_EDIT описывается (создаётся) класс lcl_event_receiver. Внутри PBO создаётся экземпляр этого класса. При этом он создаётся один раз вместе с созданием контейнера. В данном примере тоже нет экрана выбора, поэтому при выходе можно ничего не очищать. Но тут уже написано не так тщательно. Очистных конструкций нет даже в комментариях. Ну что поделать, пример недостаточно тщательно написан, цель его - показвть другие вещи. Но в итоге остаётся вопрос. Что же делать с такими объектами, как этот event_receiver, если их нужно освобождать?