Без полноценной аппаратной защитной памяти невозможно полноценно реализовать архитектуру юниксов. Значит, следует смотреть в сторону других архитектур операционных систем.Сообщение от Vitamin
Ну, может быть и так и сяк.Сообщение от Vitamin
В типичных случаях сборщик мусора скорее всего будет проигрывать по суммарной скорости. Однако, есть и другие факторы.
Для того, чтобы память систематически утекала со сборщиком мусора, необходимо специально весь мусор связывать в список, чтобы мусор оставался живым. Однако, "против" такого традиционный распределитель тем более "не поможет".Сообщение от Vitamin
Если же, например, циклически выделять и не освобождать память на имя глобального указателя, то традиционный распределитель ничего не сможет поделать. Сборщик же мусора, не обраружив ссылок на предыдущие выделенные блоки, сможет прибрать их.
Ну конечно, при каждом запросе на освобождение проверять весь список занятых блоков - тоже вариант.Сообщение от Vitamin
Неоднозначно.Сообщение от Vitamin
См. выше. Сборщик мусора вообще может располагаться ниже, чем планировщик процессов.
Да, именно так.Сообщение от Vitamin
Сборщику мусора совершенно ни к чему работать на вытесняющей многозадачности параллельно с другими, обслуживаемыми им, задачами. Он может работать только при исчерпании памяти при вызове NEW(), в рамках этой процедуры.
Так ведь у нас пока не так уж много реализовано этих самых ЯВУ.Сообщение от Vitamin
![]()
Можно сначала сделать, а потом убрать, а можно сразу сделать сборщик мусора. Тогда и делать а потом убирать ничего не придётся.Сообщение от Vitamin





Ответить с цитированием