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

[Vitamin]

Неужели я кидаюсь необоснованными заявлениями?

насчет числа книжек %)

Это можно списать на недостатки технологии Java.

может быть, пока не пришлось близко сталкиваться с этой технологией

Ответ на этот вопрос есть в упомянутой статье (мне пришлось её прочитать, чтобы посмотреть, упоминается ли там о сборщике мусора. упоминается.) Ответ - сборщик мусора является свойством распределителя памяти среды исполнения самого базового уровня.
И в инферно не "интерпретатор лимбо", а JIT-компилятор для dis.

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

Поэтому лучше не говорить, что нечто "является осью" или "не является осью".

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

Например, кто-нибудь может сказать, что на машинах без защиты памяти у ОС не может быть ядра, потому что нет "режима ядра".

ну это уже маразм %)

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

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

[Alex/AT]

его можно со спокойной совестью засвопить

На дискетку-то? Да и даже на винт... При той организации памяти, что есть сейчас, получится геморрой. Самый настоящий. Ибо ну засвопил ты 4 кб. А они находятся в другой странице, и вообще между двумя блоками других программ. Блок использовать все равно невозможно. Что делать?

[captain cobalt]

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

предложенный нами метод обеспечивает все эти пункты

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

Можно воспользоваться этой же моделью, выкинуть из неё всё ненужное и лишнее, и прикрутить сборщик мусора.

[Alex/AT]

Разумеется, центральная идея - обращаться к памяти косвено

Гы. По ~30-40 тактов на байт... чересчур.

[captain cobalt]

Гы. По ~30-40 тактов на байт... чересчур.

Не совсем так. Косвеное обращение ко всему выделенному блоку, а не каждому байту.

А по поводу тактов на байт лучше рассказать тем, у кого блоки физически копируются.

[acidrain]

Сборщик мусора - одна из составляющих программной защиты памяти. Вторая важная составляющая - строго типизированный язык высокого уровня. Эти средства пресекают практически все ошибки программирования и позволяют создавать надёжные программные системы. Надёжнее чем виндовс. Который работает с аппаратной защитой памяти.

Хммм - например мы выбрали AmigaE язык за основу всей оси, тогда спек получится ограничен одним языком, который, возможно, далеко не эффективен. Прийдется писать жабу на амиЕ, чтоб соответсвовать оси. А представь критичные по скорости проги - их как реализовывать? Тогда, проще клепать простую хард защиту памяти и иметь ее ввиду при разработке оси (т.е. разработать единый стандарт, чтоб не было потом трений), что пользователь может прикупить такой штука у дяди Васи и тада ось и спек станут супер-пупер =). Спорщик муссорА - не для спека имхо =)

[Advertiser]

[Vitamin]

Не совсем так. Косвеное обращение ко всему выделенному блоку, а не каждому байту.

А по поводу тактов на байт лучше рассказать тем, у кого блоки физически копируются.

а ты почитай внимательнее предложения. а еще лучше, просто прочитай.
к куче имеется ПРЯМОЙ доступ, для этого она и придумывалась. а блоки копируются при доступе к верхней памяти, расширенной.

[captain cobalt]

Хммм - например мы выбрали AmigaE язык за основу всей оси, тогда спек получится ограничен одним языком, который, возможно, далеко не эффективен. Прийдется писать жабу на амиЕ, чтоб соответсвовать оси. А представь критичные по скорости проги - их как реализовывать?

Да, именно это упоминалось как "недостатки технологии Java". Нужно иметь возможность реализовывать time-critical участки на ассемблере.

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

(Возможно, трения возникнут при разработке "единого стандарта").

[captain cobalt]

а ты почитай внимательнее предложения. а еще лучше, просто прочитай.
к куче имеется ПРЯМОЙ доступ, для этого она и придумывалась. а блоки копируются при доступе к верхней памяти, расширенной.

Вижу.

[Vitamin]

Вижу.

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

и ответь пожалуйста подробнее на мои вопросы по реализации требований твоим методом (несколько постов назад)