Очищать/перезаписывать ссылки на не используемые объекты, чтобы о них мог позаботиться сборщик мусора. Тут "чистые" ABAP-объекты, которые не занимаются "отображением" и взаимодействием с компонентами фронтенда.

Боюсь очистки переменной ссылающейся на объект обработчик события может не хватить. Перед очисткой, нужно снять обработчик через "activation space"
И еще вопрос к VKB
в отладке видно номер объекта грида, что-то типа {O:101*\CLASS=CL_GUI_ALV_GRID}. Можно на объект смотреть и без переменной, если в поле укакать {O:101}, после возвращения на экран выбора и запуска отчета по новой, у переменной грида меняется счетчик объекта? если да, то старый номер во втором запуске в отладке все еще виден?

Повторюсь, вникал, хотя и давно. Потому и про Borland Pascal спросил, что почуял "родственную душу".
Вот, что я понял:
Команда Free <object> чистит только переменную, т.е. ссылку на объект, но не сам объект. Вызов деструктора позволяет чистить данные объекта, но сам объект останется живым. Реально объект в памяти будет убит ТОЛЬКО уборщиком мусора, когда ему "будет угодно".
Т.о. у нас нет возможности влиять на этот процесс. И даже если выколупать какие то возможности, то смысла это не имеет, т.к. это общий стиль SAP - а, как известно, в чужой монастырь со своим уставом не ходят!

p.s.
В свое время, перейдя с паскаля на дельфи, я тоже переживал, что больше нет возможности строго контролировать объем динамической памяти, т.к. "куча" стала общей и в многозадачной среде это стало просто бессмысленным. Я убежден, что ни один программист не способен писать без ошибок (если увидите такого - пристрелите его, потому что он врет или просто лох ) и без четкого контроля памяти в ней обязательно заведутся "мертвяки". Эту проблему и решает уборщик мусора и, я полагаю, более эффективно!
К тому же в SAP-е есть некоторые фичи, построенные на том, что память не освобождается сразу после исполнения программы. Например, после вызова из одной программы другой, вы имеете доступ к глобальной памяти 2-й программы из 1-й. Хотя, казалось бы, логично после выхода из 2-й освободить её память. Особенно это касается функциональных модулей и их групп, когда один модуль задает глобальные переменные, а другой их использует - САПа насквозь прошита таким кодом. В принципе такой подход - бардак, что создает определенные трудности в программировании, но никто, кроме SAP, это не исправит. Что, кстати, SAP и делает, постепенно переходя на ООП.

Можно подробнее, как это сделать? Есть ли пример? В описании класса CL_GUI_ALV_GRID нашёл метод SET_REGISTERED_EVENTS, но внутри коммент "*!!! Do not use for ALV Grid Control Я ИДИЁТ, УБЕЙТЕ МИНЯ КТО-НИБУДЬ!" Каких-либо явных методов для отмены регистрации событий не нашёл.Номер объекта тот же получается у грида. Думаю, что это потому что он освобождается вместе с контейнером и соответственно при следующем создании они попадают на те же самые номера.

Насчёт сборщика мусора. Мне в принципе аглогритм его работы не так важен. Тем более, что я не могу на него влиять. Но помнится из того, что я читал по сборке мусора, мусором считается только тот объект, на который нет ссылок из активных переменных программы. В данном случае я не знаю, в каком состоянии остаётся грид после освобождения, если событие не деактивируется. В отладчике видно, что после освобождения контейнера переменная GRID тоже обнуляется, но соответствующий объект, на который она ссылалась {0:29} остаётся с активным событием. Однако после выхода на экран выбора и повторного запуска экрана с контейнером, объект {0:29} показывается уничтоженным (и этот номер по новой назначается гриду).

Глюков при работе программы я не заметил, но меня смущает этот активный EVENT у уничтоженного объекта.

По идее отмена регистрации происходит через добавку [ACTIVATION act].

так оно и есть, обработчик остается активным если его не снять руками set handler тру-ля-ля for тру-ля-ля activation space
то что после возвращения на экран выбора обращение к объекту по номеру(а не переменной) показывает пусто однозначно говорит о том что объекты уничтожаются -> глюков нет (по крайней мере с объектами), если в остальном порядок, то потери системные

В PBO экрана с АЛВ я активирую событие через 2 команды:Соответственно при возврате на экран выбора я могу написатьи в отладчике видно, что событие в гриде убирается.

Я не совсем понимаю смысла второй команды - grid->register_edit_event(просто переписал из примера). Вопрос - есть ли возможность (и нужно ли) ещё как-то отменять её действие? Если я, скажем, не хочу ещё пока уничтожать grid, а хочу изменить обработку этого события?

Ну и остаётся вопрос с уничтожением самого event_receiver. Я пока обошёлся тем, что описываю его один раз как глобальный объект, хотя в примере он почему-то создаётся в PBO экрана с ALV.

возврат на экран выбора чистит все глобальные переменные, так что дополнительно его очищать нет необходимости
отключать обработку события нужно если есть желание почикать объект во время выполнения
grid->register_event... вызывается для того чтобы сообщить гуишке что такое-то действие требует реакции сервера приложений
и не влияет на abap объекты никоим образом. если хочется изменить обработчик, то повторно тому же гриду сообщать ничего не надо, т.к. события(гуишные, а не abap objects'овые) уже были зарегены, достаточно, отключить объект старого обработчика и подключить новый

На практике замечал что не всегда глобальные переменные очищаются при возврате на сел. экран. Подозреваю что это связано с наличием в отчете определенных событий (Initilization, PBO на сел экран)

У меня возникла подобная ситуация "утечки памяти". Суть в том, что некие объекты (допусим <мячи>) должны реагировать на событие (допустим <удар>) другого объекта (допустим <нога>) до тех пор пока живы сами, т.е. пока на них существуют ссылки в каких-либо переменных (допустим <мячами> играют дети). Проблема в том, что как только срабатывает Set handler <мяч> к <удару> <ногой> возникает ещё одна прямая ссылка и <мяч> становится бессмертным (по сути привязан к <ноге>) и никогда не достанется уборщику мусора.
Выполнить "Set handler... activate space" можно только когда последний ребёнок наиграется <мячом> и бросит его. Но отловить этот момент средствами ABAP-а нет возможности (казалось бы), это может сделать только уборщик мусора, а он не сработает - замкнутый круг.
В других языках есть понятие "слабая ссылка", которая придумана именно для ситуаций, когда мусорщику на них плевать - бросил ребенок <мяч>, игнорируем слабую привязку к <ноге>, <мяч> в утиль.
В ABAP-е нет прямого понятия "слабая ссылка", но оказывается есть класс CL_ABAP_WEAK_REFERENCE. Передавая ему через конструктор свой объект мы создаем с слабую ссылку. Получить её можно методом Get, если вернет <пусто>, значит ссылка умерла.
В моём примере он выполняет роль посредника - <бутсы>, которая имеет сильную ссылку с <ногой> и слабую ссылку с <мячом>. От класса CL_ABAP_WEAK_REFERENCE я создал потомка <бутсу>, в нём метод обработки <удара> <ногой>. При создании <бутсы> сильно привязываем её (set handler) к <ноге>, и слабо к <мячу>. Когда у <бутсы> срабатывает метод обработки <удара>, проверяется ссылка с <мячом>. Если <мяч> жив, вызываем его метод-обработчик <удара>. Если <мяч> умер, то <бутса> делает себе харакири (set handler... activate space), т.о. убивается ненужная сильная ссылка.

p.s.
Замечено, что мусорщик не особо спешит подбирать мусор из таких "слабых" <мячей>, в отличие от обычного мусора. Поэтому <ноге> перед вызовом события <удар> полезно вызвать напрямую ленивого мусорщика через CL_ABAP_MEMORY_UTILITIES=>DO_GARBAGE_COLLECTION( ), тогда всё чисто!