AVC>На случай злобного хакера, можно подумать о технологии "тонких бинарников". AVC>Модуль попадает в систему в полукомпилированном виде, докомпилируется при загрузке. AVC>В принципе, можно докомпилировать один раз, потом грузить бинарник.
Именно так предполагается делать в Singlularity.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, vdimas, Вы писали: V>Угу, пока речь не пойдет об GUI. Тут и настанет сказочке конец. Покажи сегодня хоть одну большую прогу с богатым GUI, которая не на плагинной системе сделана. Под тысячу переданных сообщений GUI м/у процессами в секунду? Это круто.
Это детский лепет. На сингулярити стоимость обмена сообщениями в 6 раз ниже, чем в Windows: http://rsdn.ru/article/singularity/singularity.xml#EIIAE
Здравствуйте, vdimas, Вы писали:
V>Сетевой протокол CORBA очень продуман, и легко расширяем, в отличие от ремотинга донета.
У ремоутинга нет сетевого протокола.
V> Я имею ввиду, что если будет желание, например, как-то расширить стандартный ремотинг путем своих каналов или там еще чего (для передачи, скажем, неких атррибутов, привязанных к конкретным вызовам методов удаленных объектов), то это вступит в конфликт с другими компонентами системы
VD>Конкурируютя алгоритмы. Вот для того же дотнета и Явы есть 2-4 алгоритма для каждой из платформ. VD>И Ява и дотнет жувут с одной реализацией и являются лидерами. Тут даже обсуждать нечего.
Вообще-то в jre реализовано несколько алгоритмов сборки мусора
Здравствуйте, NorthDragon, Вы писали:
ND>Вообще-то в jre реализовано несколько алгоритмов сборки мусора
В дотнете тоже несколько алгоритмов. Но реализация одна. В прочем для Явы действительно есть раелизации от разных поставщиков, но нельзя не признать, что большинству людей достаточно реализации от Sun-а.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>В дотнете тоже несколько алгоритмов. Но реализация одна. В прочем для Явы действительно есть раелизации от разных поставщиков, но нельзя не признать, что большинству людей достаточно реализации от Sun-а.
Кстати, реализаций от сантехников несколько. При том, некоторые появившиеся раньше — "устаревшие". То биш жизнь идёт. Если бы "всем хватало", то не появлялось бы там ничего нового. Что касается дот-нета, то судя по тем крохам, что есть я видел в документации, то отстают они от сан-техников.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Что касается дот-нета, то судя по тем крохам, что есть я видел в документации, то отстают они от сан-техников.
По моим наблюдениям пямять .NET 2.0 кушает раза в 2 как минимум меньше чем JRE любая, при этом не медленнее.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Кстати, реализаций от сантехников несколько.
Озвучь, плиз список. Толко не надо говорить о серверном и клиентском ЖЦ. Это как я уже сказал одна реализация двух алогритмов заточенных под разные условия использования.
ANS> При том, некоторые появившиеся раньше — "устаревшие". То биш жизнь идёт.
Это прошлые версии. Они, кстати, мало чем отличаются. Нормальная эволюция.
ANS>Если бы "всем хватало", то не появлялось бы там ничего нового.
Реально всем хватает. Но конечно совершенсту нет пределов. Вот только нове появляется не в следствии реальной конкуренции, а в следствии работы ислледовтельских коллектиово. А уже наработанные идеи опробируются и влючаются в промышленные реализации коих очень не много (практически по одной на платформу).
ANS> Что касается дот-нета, то судя по тем крохам, что есть я видел в документации, то отстают они от сан-техников.
ЖЦ дотнета на сегодня во многом лучше Сановского. Особенно если речь вести о клиенстком ЖЦ. Более того потенциально он даже сменный. Вот только вдяд ли кто-то осилит создать полноценный ЖЦ вне стен МС, так как он слишком сильно завязан с джитом, а инофрмации крайне мало.
ЗЫ
Вообще ЖЦ сегодня это всокотехнологичный софт обросший тучей сплетен, домыслов и другой ахинеии. Большинство программистов не понимают принципов их работы и выдумывают о них всякий вздор.
Реально умные мысли о ЖЦ есть только у их разработчиков и ислледователей. Но это уже научная область и большинство программистов банально не могут в нее влезть из-за объема необходимых знаний.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2 wrote: > ANS>Кстати, реализаций от сантехников несколько. > Озвучь, плиз список. Толко не надо говорить о серверном и клиентском ЖЦ. > Это как я уже сказал одна реализация двух алогритмов заточенных под > разные условия использования.
Не совсем.
Ну ладно, вот весь список:
1. Serial Generational GC (обычный последовательный GC).
2. Parallel Generational GC (тоже самое, что и последовательный, но во
время сборки мусора его собирают сразу все процессоры).
3. Concurrent Mark&Sweep GC, a.k.a. Tricolor GC (инкрементальный
параллельный GC).
4. Mostly-Concurrent Generational GC (Generational GC, который работает
почти параллельно с мутатором).
Причем они могут настраиваться и комбинироваться. Например, у
generational'ов можно включать или выключать компактификацию поколений,
менять trigger policies. Mark&Sweep можно сочетать с generational'ами и т.п.
У меня лежит незаконченая статья, все дописать никак не могу.
Здравствуйте, Cyberax, Вы писали:
C>Ну ладно, вот весь список: C>1. Serial Generational GC (обычный последовательный GC). C>2. Parallel Generational GC (тоже самое, что и последовательный, но во C>время сборки мусора его собирают сразу все процессоры). C>3. Concurrent Mark&Sweep GC, a.k.a. Tricolor GC (инкрементальный C>параллельный GC). C>4. Mostly-Concurrent Generational GC (Generational GC, который работает C>почти параллельно с мутатором).
И что это за список?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали: ANS>>Кстати, реализаций от сантехников несколько.
VD>Озвучь, плиз список. Толко не надо говорить о серверном и клиентском ЖЦ. Это как я уже сказал одна реализация двух алогритмов заточенных под разные условия использования.
Вот есть операция деления. Но есть разные реализации. Так же есть "tracing" и "copying" GC. И есть разные реализации, которые имеют те или иные выгоды.
ANS>> При том, некоторые появившиеся раньше — "устаревшие". То биш жизнь идёт.
VD>Это прошлые версии. Они, кстати, мало чем отличаются. Нормальная эволюция.
Фига се мало. Ознакомся с материалом для начала.
ANS>> Что касается дот-нета, то судя по тем крохам, что есть я видел в документации, то отстают они от сан-техников.
VD>ЖЦ дотнета на сегодня во многом лучше Сановского.
Трындеть — не мешки ворочать. Как на счет привести доказательства. Только умоляю — не нужно этих "Мамой клянусь".
VD>Особенно если речь вести о клиенстком ЖЦ.
Не нужно нам военных песен, нам факты давай!
VD>Более того потенциально он даже сменный. Вот только вдяд ли кто-то осилит создать полноценный ЖЦ вне стен МС, так как он слишком сильно завязан с джитом, а инофрмации крайне мало.
Угу. У сантехников информации как кот наплакал, но и её в сотни раз больше чем у МС. Эти вообще всё просто решили: есть серверный GC — юзайте его на серверах. А то что этот GC весь сервер колом ставит — так это пофиг. В результате если хип занимает пару гиг, то полный GC, даже на нескольких процах, занимает несколько десятков секунд. За это время набирается очередь запросов и сервер колбасит потом еще долго. Такое ощущение, что кроме как на замену PHP никто .Net на серверах не использует.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS> Вот есть операция деления. Но есть разные реализации. Так же есть "tracing" и "copying" GC. И есть разные реализации, которые имеют те или иные выгоды.
Ясно. Ты не понимаешь разницы между реализацией и алгоритмом. Один ЖЦ в зависимости от настроек может применять разные алгоритмы. Дотнет и Ява тому пример. А раелизация тем временем одна.
ANS>Фига се мало. Ознакомся с материалом для начала.
Тут ни слова про разные реализации.
ANS>Трындеть — не мешки ворочать. Как на счет привести доказательства. Только умоляю — не нужно этих "Мамой клянусь".
Дык не трынди. Кто же тебя заставляет?
Доказательства тут баральные качаешь JEdit открываешь в нем файлик в несколкь мег и колдишь как ЖЦ дает о себе знать невооруженному взгляду. А потом качаешь мой Rsdn.Editor и убеждаешься, что ЖЦ вообще не заметен на глаз.
VD>>Особенно если речь вести о клиенстком ЖЦ.
ANS>Не нужно нам военных песен, нам факты давай!
Чтобы трындеть было сподручнее?
Дык ты и так трындишь без проблем. Не уж-то и впрямть что-то сокровенное из документации вычитал?
ANS>Угу. У сантехников информации как кот наплакал, но и её в сотни раз больше чем у МС. Эти вообще всё просто решили: есть серверный GC — юзайте его на серверах.
Ну, это ты по незнанию говоришь. Вообще-то есть и Rotor, и книжки по MS-ному GC. Но для поддержания трындежа это конечно не важно.
ANS> А то что этот GC весь сервер колом ставит — так это пофиг.
У трындельщиков то? Несомненно. Только причем тут софт? Тут дело в прослойке.
ANS> В результате если хип занимает пару гиг, то полный GC, даже на нескольких процах, занимает несколько десятков секунд.
Серьезно? Можно глянуть сервер находящийся в твоем распоряжении где стоит дотнет и где хип занимает пару гиг? А? А то я не видел ни разу. У нас вот 500 мег не превышает (к сожалению). И сборки идут со скоростью сотен в секудну.
Что мы не так делаем?
ANS> За это время набирается очередь запросов и сервер колбасит потом еще долго. Такое ощущение, что кроме как на замену PHP никто .Net на серверах не использует.
Ты говоришь о том о чем и представления никакого не имеещь. А мне такие беседы не интересны.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Ясно. Ты не понимаешь разницы между реализацией и алгоритмом. Один ЖЦ в зависимости от настроек может применять разные алгоритмы. Дотнет и Ява тому пример. А раелизация тем временем одна.
Одна реализация разных алгоритмов? Расшифруй.
ANS>>Фига се мало. Ознакомся с материалом для начала.
VD>Тут ни слова про разные реализации.
VD>Доказательства тут баральные качаешь JEdit открываешь в нем файлик в несколкь мег и колдишь как ЖЦ дает о себе знать невооруженному взгляду. А потом качаешь мой Rsdn.Editor и убеждаешься, что ЖЦ вообще не заметен на глаз.
То есть цифр не будет, ибо для тебя доказательство — это "на глаз"?
(Кстати, что есть "колдишь"?)
ANS>>Угу. У сантехников информации как кот наплакал, но и её в сотни раз больше чем у МС. Эти вообще всё просто решили: есть серверный GC — юзайте его на серверах.
VD>Ну, это ты по незнанию говоришь. Вообще-то есть и Rotor, и книжки по MS-ному GC. Но для поддержания трындежа это конечно не важно.
Для понимания GC в .Net сырцы ротора представляет такую же ценность как и сырцы gc в jvm. Что касается книжек, то давай ссылку на amazon.
VD>У нас вот 500 мег не превышает (к сожалению). VD>И сборки идут со скоростью сотен в секудну.
На таком крохотном хипе даже счетчик ссылок будет работать без проблем.
% Time in GC: 78%
И так: 500М нетути, но картина уже грустновата. А если хип увеличиться в 10 раз, то клиенты вообще ответа от него не дождутся.
ANS>> За это время набирается очередь запросов и сервер колбасит потом еще долго. Такое ощущение, что кроме как на замену PHP никто .Net на серверах не использует.
VD>Ты говоришь о том о чем и представления никакого не имеещь. А мне такие беседы не интересны.
Andrei N.Sobchuck wrote: > Для понимания GC в .Net сырцы ротора представляет такую же ценность как > и сырцы gc в jvm. Что касается книжек, то давай ссылку на amazon.
Сырцы в JVM вполне, кстати, помогают понять как JVM работает. Особенно
тонкие его детали, типа используемого write barrier.
А вот Ротор — он действительно ничем не поможет, там примитивный GC.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Одна реализация разных алгоритмов? Расшифруй.
Алгоритмы используются в рамках одной реализации ЖЦ. Вот IBM, например, предоставляет свою реализацию. Еще кто-то может быть. А у Сана реализация одна.
Точно так же и у МС. Алноритмов Х, а реализация одна.
VD>>Доказательства тут баральные качаешь JEdit открываешь в нем файлик в несколкь мег и колдишь как ЖЦ дает о себе знать невооруженному взгляду. А потом качаешь мой Rsdn.Editor и убеждаешься, что ЖЦ вообще не заметен на глаз.
ANS>То есть цифр не будет, ибо для тебя доказательство — это "на глаз"?
Если видны тормоза от сборки мусора на глаз, значит задкржки доходят до десятых долей секунды и больше. Я надеелся твоего интеллекта хватит на то чтобы сдалать такой логический вывод.
.
ANS>Для понимания GC в .Net сырцы ротора представляет такую же ценность как и сырцы gc в jvm. Что касается книжек, то давай ссылку на amazon.
Может тебе ссылку на гугль дать?
VD>>У нас вот 500 мег не превышает (к сожалению). VD>>И сборки идут со скоростью сотен в секудну.
ANS>Это на "сотни в секунду" не тянет
Сборка мусора нулевого поколения просходит раз 1-4 секунды. Раз в 10 секунд просходит сборка второго поколения. Где-то так же первого.
.
И? Ты вообще знаешь чем скорость от частоты отличается? И за одно чем отличается "в среднем" от "в пиковые моменты"?
VD>>Что мы не так делаем?
ANS>Ты просто не умееш читать. Смотрим
:
ANS>Поколение 0: 37М ANS>Поколение 2: 26М
ANS>На таком крохотном хипе даже счетчик ссылок будет работать без проблем.
ANS>% Time in GC: 78%
ANS>И так: 500М нетути, но картина уже грустновата. А если хип увеличиться в 10 раз, то клиенты вообще ответа от него не дождутся.
Слушай откровенно говоря я сейчас скачусть на нелестные отзывы о твоей личности, так как твоя изберательность в цитировании и понимании чужих слов никак окромя демагогии назвать нельзя.
Спустись на пару веток ниже Re[10]: GC в .NET
Здравствуйте, Cyberax, Вы писали:
C>Сырцы в JVM вполне, кстати, помогают понять как JVM работает. Особенно C>тонкие его детали, типа используемого write barrier.
Тьфу-тьфу-тьфу. До копания сырцов gc в java для оптимизации приложения дело не дошло. К счастью, на их форуме по jvm отвечают на вопросы и разработчики. Из которых вполне можно вытащить ответы, при наличии терпения Найденную багу в инкрементальном конкурентном GC при работе со слабыми ссылками они пофиксили, кстати, в несколько дней. А вот общение на форуме по коллекциям никакого удовольствия не приносит Там багу в сырцах AbstractMap не хотят даже признавать
Здравствуйте, VladD2, Вы писали:
VD>Если видны тормоза от сборки мусора на глаз, значит задкржки доходят до десятых долей секунды и больше. Я надеелся твоего интеллекта хватит на то чтобы сдалать такой логический вывод.
Что задержки именно от сборки мусора, а не от того, тчо программа такая это ты инфу из астрала получил?
VD>Привести тебя цифры даже не прошу. Ты же у нас производительность ЖЦ по документации изучаешь
Именно по цифрам. Вот лог от сборки в Эдэме (молодом поколении):
Desired survivor size 41464624 bytes, new threshold 4 (max 6)
— age 1: 25402832 bytes, 25402832 total
— age 2: 13157352 bytes, 38560184 total
— age 3: 1943640 bytes, 40503824 total
— age 4: 1154792 bytes, 41658616 total
— age 5: 1800272 bytes, 43458888 total
: 469376K->42624K(469376K), 0.2825171 secs] 908653K->498107K(8345984K), 0.2832459 secs]
ANS>>Для понимания GC в .Net сырцы ротора представляет такую же ценность как и сырцы gc в jvm. Что касается книжек, то давай ссылку на amazon.
VD>Может тебе ссылку на гугль дать?
То есть нету. Я так и думал.
VD>>>У нас вот 500 мег не превышает (к сожалению). VD>>>И сборки идут со скоростью сотен в секудну.
ANS>>Это на "сотни в секунду" не тянет
VladD2 wrote: > ANS>Одна реализация разных алгоритмов? Расшифруй. > Алгоритмы используются в рамках одной реализации ЖЦ. Вот IBM, например, > предоставляет свою реализацию. Еще кто-то может быть. А у Сана > реализация одна. > Точно так же и у МС. Алноритмов Х, а реализация одна.
Вообще-то, внутри JDK алгоритмы GC находятся в раздельных модулях и
вполне себе автономны.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Что задержки именно от сборки мусора, а не от того, тчо программа такая это ты инфу из астрала получил?
Это совершенно очевидно. Тормоза случаются переодически при скролинге. Если бы проблема была алгоритмической, то тормоза были бы постоянно. А так они происходят через определенный промежуток времени. Ели тебе интересно, можешь поглядеть чем-нибудь информацию о сборках.
VD>>Привести тебя цифры даже не прошу. Ты же у нас производительность ЖЦ по документации изучаешь
.
ANS>Именно по цифрам. Вот лог от сборки в Эдэме (молодом поколении): ANS>
ANS>Desired survivor size 41464624 bytes, new threshold 4 (max 6)
ANS>- age 1: 25402832 bytes, 25402832 total
ANS>- age 2: 13157352 bytes, 38560184 total
ANS>- age 3: 1943640 bytes, 40503824 total
ANS>- age 4: 1154792 bytes, 41658616 total
ANS>- age 5: 1800272 bytes, 43458888 total
ANS>: 469376K->42624K(469376K), 0.2825171 secs] 908653K->498107K(8345984K), 0.2832459 secs]
Назовц фиры! 1, 295, 18, 4! Это реальны цыфры!!!
Ты делал заявления по повду ЖЦ дотнета в сравнении с Явой. Вот по этому поводу цифры и проводи, а какю-то фигню.
ANS>То есть нету. Я так и думал.
Ну, почему же? http://www.google.ru/
Дальше справишся?
ANS>Со скоростью "сотен в секунду" чего? Сотен объектов? Единица измерения какая?
Сборок, сборок. Нулевое поколение собирается за микросекунды.
ANS>Могу предположить, что этот "явный глюк" был сборкой 2-го поколения.
Ты можешь что угодно предполагать. Меж тем во время сборки мусора мог банально захватить процессор MSSQL и статистика стала черт знает какой. Что произошло конкретно можно только гадать. Меж тем это и не важно. Сказано же, что это отдельное редко встречаемое явление.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
1.2.0 alpha rev. 655
Вот есть операция деления. Но есть разные реализации. Так же есть "tracing" и "copying" GC. И есть разные реализации, которые имеют те или иные выгоды.
Найденную багу в инкрементальном конкурентном GC при работе со слабыми ссылками они пофиксили, кстати, в несколько дней. 
А вот общение на форуме по коллекциям никакого удовольствия не приносит 