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

Цитата:

---

Сообщение от captain cobalt

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

---

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

Цитата:

---

Сообщение от captain cobalt

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

---

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

Цитата:

---

Сообщение от captain cobalt

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

---

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

Цитата:

---

Сообщение от captain cobalt

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

---

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

Цитата:

---

Сообщение от captain cobalt

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

---

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

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

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

Цитата:

---

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

---

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

Цитата:

---

Сообщение от Vitamin

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

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

---

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

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

Цитата:

---

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

---

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

Цитата:

---

Сообщение от Alex/AT

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

---

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

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

Цитата:

---

Сообщение от captain cobalt

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

---

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

Цитата:

---

Сообщение от captain cobalt

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

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

---

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

Цитата:

---

Сообщение от acidrain

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

---

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

Цитата:

---

Сообщение от acidrain

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

---

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

Цитата:

---

Сообщение от Vitamin

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

---

Вижу.

Цитата:

---

Сообщение от captain cobalt

Вижу.

---

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

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