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

Вид для печати

Показывать 40 сообщений этой темы на одной странице

01.04.2005, 07:02
captain cobalt

Цитата:

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

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

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

Цитата:

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

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

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

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

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

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

Цитата:

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

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

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

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

Цитата:

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

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

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

Цитата:

Сообщение от elf/2

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

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

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

ОК. Буду думать.
01.04.2005, 23:51
Vitamin

Цитата:

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

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

Цитата:

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

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

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

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

Цитата:

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

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

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

Цитата:

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

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

фу.... как негигиенично %)
02.04.2005, 07:14
captain cobalt

Цитата:

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

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

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

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

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

Цитата:

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

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

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

20 против 3 достаточный показатель...
02.04.2005, 21:28
Vitamin

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Показывать 40 сообщений этой темы на одной странице