MODULE  sgTest003;
IMPORT  StdLog;

PROCEDURE   Проверка*;
  TYPE A = POINTER TO ARRAY 10000000 OF INTEGER;
  VAR a: A;
BEGIN
  StdLog.String(" Создаю "); StdLog.Ln();
  NEW(a);    (* В этом месте я вижу через Windows Task Manager  как BlackBox забрал
память*)
  StdLog.String(" Выхожу из области видимости "); StdLog.Ln();
  a := NIL; (* Я думаю, что сборщик мусора должен активизироваться в этом месте *)
END Do;
(* В этом месте я ожидаю, что BlackBox отдаст память обратно в распоряжение Windows
XP*)

BEGIN
END  sgTest003.

(Коммандер)sgTest003.Проверка

Ответ на »сообщение 95« (Илья Ермаков)
___________________________
А что мы будем делать со ссылками на выгружаемые объекты?

Ответ на »сообщение 95« (Илья Ермаков)
___________________________

В принципе, с механизмом Internalize/Externalize можно проделывать интересные вещи.

Ничего удивительного -- ведь это и есть средство сохранения связей и внутренних состояний программных сущностей (не только объектов) с целью их последующего восстановления. Вы точно уловили идею "приморозки" модулей, когда нужна их подмена. Задача упирается в относительно несложную вещь -- регламентирование контрактов/протоколов межмодульных связей.

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

Ответ на »сообщение 92« (AVC)
___________________________

Ответ на »сообщение 85« (Илья Ермаков)
___________________________
Интересная мысль.
ИМХО, как раз в правильном направлении.
Это стоит хорошо обдумать.

Немного отходя в сторону от конкретного вопроса: имеет ли смысл приспособить механизм Externalize/Internalize для организации обмена данными (хотя бы через виндовые сообщения) между параллельно работающими Черными Ящиками?

В принципе, с механизмом Internalize/Externalize можно проделывать интересные вещи. Развивая мысль про подмену модулей... Представим себе, что в адаптивных (назовем так) модулях мы экспортируем только динамические типы, которые умеют выгружаться/загружаться в потоки (чтобы не наследовать их от одного типа, можно применить ООП в стиле Оберона-1 - поля Externalize/Internalize процедурного типа, и доступ к ним идет символически). Кроме того - обязательное условие - формат загрузки/выгрузки для экспортированных типов модуля описан. Тогда можно создать другую версию этого модуля, которая умеет загружаться (и загружать каждый свой экспортированный тип) из потока такого стандартного формата. Тогда подмена модуля на лету становится не сложнее обычной сборки мусора. Выполнение замораживается. Ищутся все экземпляры типов модуля. Их состояние выгружается в поток. Выгружается в поток состояние модуля в целом. Затем модуль выгружается. Загружается новая версия, загружается состояние из потока. Создаются новые экземпляры типов, загружается их состояние их потока. Затем указатели на эти экземпляры подменяются во всех местах. Выполнение возобновляется.
То есть, получается надежный механизм "изъятия из оборота" старых объектов и "эмиссии" новых.

Ответ на »сообщение 91« (info21)
___________________________

Ответ на »сообщение 77« (Trurl)
___________________________

Адреса процедур также хранятся в местах, доступных сборщику мусора.

Да, но <...>

Что-то я перестал понимать...
(Правда, может, заклинило. :) )
А вы оба, похоже, хорошо поняли друг друга. :)
Что значит "адреса процедур также хранятся в местах, доступных сборщику мусора"?
Если я не ошибаюсь, сборщик мусора не знает о процедурных переменных, а знает только о методах.
Может быть, поясните?

Ответ на »сообщение 85« (Илья Ермаков)
___________________________


Однако идея "адаптивной модульности", когда подмена происходит прозрачно для самой системы - штука интересная. Здесь потребуется, чтобы различные реализации были совместимы "по состоянию" и могли выгружаться/загружаться в перманентный поток. Тогда для замены модуля на лету проделываем: ModuleA.Externalize(memoryStore); Unload(ModuleA); Load(ModuleB); ModuleB.Internalize(memoryStore).

Интересная мысль.
ИМХО, как раз в правильном направлении.
Это стоит хорошо обдумать.

Немного отходя в сторону от конкретного вопроса: имеет ли смысл приспособить механизм Externalize/Internalize для организации обмена данными (хотя бы через виндовые сообщения) между параллельно работающими Черными Ящиками?

Ответ на »сообщение 77« (Trurl)
___________________________

Ответ на »сообщение 74« (AVC)
___________________________

Адреса процедур также хранятся в местах, доступных сборщику мусора.

Да, но сборщик мусора может как-то трюкачить -- битики куда-то вставлять, указатели в обратную сторону выставлять, и т.п.
Кроме того, ссылка на процедуру в модуле -- как ссылка на поле в середини записи.
Как-то все это неудобно. С дескрипторами проще.

Ответ на »сообщение 89« (Андрей Хохлов)
___________________________


Много вариантов получается...

Вот. Гибкость. :)

Ответ на »сообщение 88« (AVC)
___________________________

Много вариантов получается...
1.Объект может размещаться где угодно (RECORD)
2.Объект может размещаться только в куче (POINTER TO RECORD)
3.Возможность вызова метода зависит от того, где размещен объект (не могу это сейчас проверить)

Ответ на »сообщение 86« (Андрей Хохлов)
___________________________

Еще вопрос. В КП (и O2?) метод может привязываться к записи и указателю на запись. И это можно смешивать
<...>
Какой в этом смысл?

Единственное, что сразу приходит в голову -- чтобы управлять применимостью разных методов.
Метод с указателем -- только для объектов в куче.
IN -- константный метод, не меняющий объект.
VAR -- общий случай.
Кроме того, еще есть implement-only методы (с минусом) -- вызывается только из модуля, где был определен впервые.