Сборка мусора

[captain cobalt]

ты забыл о спектрумовской структуре памяти. забыл о том что одновременно адресовать можно только 64 кило и не больше. причем из них приложению принадлежит максимум 16. или ты думаешь что 16 кило нижней памяти хватит на кучу для системы и для всех процессов? сильно в этом сомневаюсь.... да и к тому же защищенность практически никакая в таком случае

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

А что? Делать кучи по одной странице 16К? Кучки. И нельзя в одной куче иметь указатель на блок в другой? Мне не нравится.

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

Здесь уже пошла зависимость от реализации. Но как минимум CALL и RET никуда не денутся.

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

А также, при ошибках программирования, утечку памяти и висящие указатели.

со сборщиком:
на N блоков памяти имеем N вызовов освобождения

Откуда вызовы освобождения?

N указателей на блоки

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

N коррекций этих указателей, М просмотров цепочек (при периодической проверке живых блоков)

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

что быстрее?

Это не всегда абсолютный приоритет.

[Advertiser]

[Vitamin]

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

А что? Делать кучи по одной странице 16К? Кучки. И нельзя в одной куче иметь указатель на блок в другой? Мне не нравится.

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

Здесь уже пошла зависимость от реализации. Но как минимум CALL и RET никуда не денутся.

а куда они деваются при сборщике?

А также, при ошибках программирования, утечку памяти и висящие указатели.

хех. забудем обнулить указатель для сборщика и у нас тоже чета откудато потечет %)

Откуда вызовы освобождения?

ну сборщик их же вызывает чтобы освободить неиспользуемые блоки

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

а если будет?

Это не всегда абсолютный приоритет.

в условиях жестокой ограниченности процессорных ресурсов это один из абсолютных приоритетов