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

[captain cobalt]

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

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

а если некорректная работа то и сборщик не поможет

Некоторые проблемы сборщик частично решает:

1. Повторное овобождение памяти.
Простые распределители могут сокрушить всю кучу при попытке повторного освобождения. Можно проверять корректность освобождаемого указателя, но это потребует некоторых дополнительных расходов.
Со сборщиком мусора операции освобождения нет. Все операции освобождения инкапсулированы внутри сборщика мусора. Довольно нетрудно добиться, чтобы они все были корректными. А значит можно будет не проверять их корректность. Таким образом, со сборщиком мусора все операции освобождения памяти, происходящие в системе, будут корректными.

Можно сказать, проблема некорректного освободения решена.

2. Обращение к освобождённой памяти.
Наверняка рано или поздно приведёт к крушению всей системы. Традиционный распределитель ничем не сможет помочь.
Сборщик мусора не будет освобождать память, пока существует возможность обращения к ней.

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

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

Неприменимо.
Долой вытесняющую многозадачность на Speccy.

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

Подавляющая часть систем со встроенным сборщиком мусора.

асемблер тоже на голом процессоре рулит. но это же не операционка. а я тебя прошу назвать именно операционку. посмотри на название темы. я там сочетания ЯВУ не вижу чета....

Они не используют нижележащую ОС и на них можно запускать программы написанные на этих ЯВУ.

да я тебе за это уже десятый пост твержу

Тоже могу повторить, что сборщик мусора поверх распределителя с монопольным захватом памяти - никуда не годится по эффективности. Ещё подробнее объяснить почему?

побайтовый менеджер может быть любым!

Как насчёт того, чтобы побайтовый менеджер мог быть любым и рулил внутри блоков, управляемыми менеджером со сборщиком мусора?

[Advertiser]

[Alex/AT]

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

[Vitamin]

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

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

Некоторые проблемы сборщик частично решает:

1. Повторное овобождение памяти.
Простые распределители могут сокрушить всю кучу при попытке повторного освобождения. Можно проверять корректность освобождаемого указателя, но это потребует некоторых дополнительных расходов.
Со сборщиком мусора операции освобождения нет. Все операции освобождения инкапсулированы внутри сборщика мусора. Довольно нетрудно добиться, чтобы они все были корректными. А значит можно будет не проверять их корректность. Таким образом, со сборщиком мусора все операции освобождения памяти, происходящие в системе, будут корректными.

Можно сказать, проблема некорректного освободения решена.

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

2. Обращение к освобождённой памяти.
Наверняка рано или поздно приведёт к крушению всей системы. Традиционный распределитель ничем не сможет помочь.
Сборщик мусора не будет освобождать память, пока существует возможность обращения к ней.

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

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

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

Подавляющая часть систем со встроенным сборщиком мусора.

ну назови хоть одну! слабо?

Они не используют нижележащую ОС и на них можно запускать программы написанные на этих ЯВУ.

на голом процессоре нету никакой нижележащей ОС. не увиливай от ответа

Тоже могу повторить, что сборщик мусора поверх распределителя с монопольным захватом памяти - никуда не годится по эффективности. Ещё подробнее объяснить почему?

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

Как насчёт того, чтобы побайтовый менеджер мог быть любым и рулил внутри блоков, управляемыми менеджером со сборщиком мусора?

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

[Vitamin]

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

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

[captain cobalt]

ОК. По теме больше осмысленных разговоров видимо не получится.

ну назови хоть одну! слабо?
на голом процессоре нету никакой нижележащей ОС. не увиливай от ответа

Видимо, не понимаю вопрос (почему названное не ОС).
Можно считать сдаюсь. А что это за ОС?

А вот не возникало ли вопросов, зачем и почему там сделан сборщик мусора? Почему и зачем в Inferno - потомке Unix, способном работать на машинах без защиты памяти, используется сборщик мусора?

блеск! логика обалденная, снимаю шляпу (вместе с джинсами).

(Ага! Не иначе как письками меряться!)

у тебя есть идеи как это реализовать на speccy или готовая реализация?

если нет то предлагаю заморозить дискуссию до момента появления как минимум спецификации (от тебя или кого-либо другого)

без спецификации дискуссия бессмысленна, поскольку (как мне кажется) каждый говорит о чем то своем и флейма набралось на 6 страниц...

ОК. Буду думать.

[Vitamin]

ОК. По теме больше осмысленных разговоров видимо не получится.
Видимо, не понимаю вопрос (почему названное не ОС).
Можно считать сдаюсь. А что это за ОС?

Зональный (zone) распределитель памяти, используемый в системах Mach и OSF/1, обладает возможностью быстрого выделения памяти и сбора мусора.

ю.вахалия "unix изнутри", стр.561

кста, очень советую почитать. много чего интересного сможешь почерпнуть на эту тематику.


вопрос на засыпку. можно ли назвать осью прошивку микроконтроллера?

А вот не возникало ли вопросов, зачем и почему там сделан сборщик мусора? Почему и зачем в Inferno - потомке Unix, способном работать на машинах без защиты памяти, используется сборщик мусора?

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

(Ага! Не иначе как письками меряться!)

фу.... как негигиенично %)

[captain cobalt]

ю.вахалия "unix изнутри", стр.561

кста, очень советую почитать. много чего интересного сможешь почерпнуть на эту тематику.

Да, есть у меня эта книга. но
"горе тому, кто читает только одну книгу" (с)

На правах оффтопика:
Вот мы выяснили, что в Inferno тоже сборщик мусора. Если Inferno - это ось, то почему Java OS-и - не оси? Они устроены практически точно также как Inferno, с точностью до замены dis - на JVM, а Limbo - на Java.
Из потомков Оберона наиболее современным и технологически совершенным является Bluebottle - http:/bluebottle.ethz.ch/ (тоже со сборщиком мусора). Является ли он осью?

вопрос на засыпку. можно ли назвать осью прошивку микроконтроллера?

Не удивлюсь, если по этому поводу есть более одного мнения.
А можно ли микроядро назвать осью?

[GriV]

20 против 3 достаточный показатель...

[Vitamin]

Да, есть у меня эта книга. но
"горе тому, кто читает только одну книгу" (с)

кто сказал что только одну? если у тебя сложилось такое мнение, могу сказать что по моим ощущениям, ты ни одну не читал %)
все что у меня есть по данной тематике, я прочел. начиная от "сетевые операционные системы" олифера и заканчивая "внутреннее устройство ядра линукс 2.4" айвазяна.

На правах оффтопика:
Вот мы выяснили, что в Inferno тоже сборщик мусора. Если Inferno - это ось, то почему Java OS-и - не оси? Они устроены практически точно также как Inferno, с точностью до замены dis - на JVM, а Limbo - на Java.

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

Из потомков Оберона наиболее современным и технологически совершенным является Bluebottle - http:/bluebottle.ethz.ch/ (тоже со сборщиком мусора). Является ли он осью?

про оберон не знаю абсолютно ничего, поэтому на этот вопрос ничего не могу сказать.

Не удивлюсь, если по этому поводу есть более одного мнения.
А можно ли микроядро назвать осью?

смотря какое микроядро. если брать например изначальные варианты qnx, то с большой натяжкой. современные версии- полноценные оси.

[captain cobalt]

могу сказать что по моим ощущениям, ты ни одну не читал %)

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

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

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

так что инферно вполне можно приписать к тому списку ос со встроенным сборщиком мусора. да и то, ответь мне на вопрос- это ось обеспечивает эту сборку, или интерпретатор лимбо?

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

смотря какое микроядро. если брать например изначальные варианты qnx, то с большой натяжкой. современные версии- полноценные оси.

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