Andrei N.Sobchuck wrote:
> C>Ничего кроме простенького mark&sweep в такие рамки положить не
> C>получится, а от него мало толку будет.
> Ладно ладно. Спорить не буду. А у тебя есть, что сказать про compile
> time GC (O'Caml)?
Region inference — он часто дает слишком пессимистичные результаты.

Дарней wrote:
> C>А еще функции должны работать только с ограниченым по размеру
> C>окружением.
> это уже забота ВМ
А как ты будешь убеждаться, что твой код не требует больше 256Кб памяти?

> C>И без всякого GC — он в 256Кб не поместится.
> как насчет region inference?
Пессимистично слишком.

> C>Так что С++ все же в более выгодном положении.
> Делать все вручную?
Да, и для этого есть необходимые инструменты (умные указатели, механизм
деструкторов и т.п.). Еще необходимо добавить прагмы для обозначения
кода для SPU и соответствующую поддержку компилятора.

WolfHound wrote:
> C>Тем не менее, функциональные вычисления генерируют кучу мусора. А это
> неприемлимо.
> Это очень сильно зависит от алгоритма и от оптамизатора.
Нет, к сожалению.

> C>Нефиг в софте переделывать то, что прекрасно делается в железе
> В том то и дело что плохо оно делается... в железе можно эффективно
> добится изоляции только довольно крупных кусков памяти иначе будет тАкой
> оверхед что мама не горюй.
Ага, а тут у нас этот оверхед будет в софте. _Сегодняшнее_ _х86-железо_
действительно ориентировано на процессы, однако ничего не мешает сделать
более эффективную аппратную изоляцию.

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

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

> C>(тем более, что тенденция сейчас совсем обратная).
> Ага... Жаба и .НЕТ захватывают рынок... Делаются Жаба процессоры...
> Новый софт начинают писать на С++ все реже и реже...
...деревня Нью Васюки становится центром шахматного мира...

Ну не вижу я захвата рынков. Ява где была 5 лет назад — там и осталась.
То есть на серверах и в корпоративных приложениях. Как и .NET.

> C>Первое преимущество для SPU не так важно,
> Кроме SPU есть еще куча других архитектур... на них софт тоже должен
> работать...
На многих архитектурах работает Windows XP? А RSDN@Home?

> C>второе — на любителя (аппаратная поддержка же есть).
> То-то программы постоянно взламывают через переполнение буфера... Да и
> просто падение программы на ровном месте ничего хорошего не дает. Вот
> только не говори что это лечится прямыми руками... у кого эти прямые
> руки есть? Правильно у *очень небольшой *части программистов.
Пусть остальные программисты пишут на .NET — я не против. Другое дело,
что управляемые ОС _лишают_ возможности писать на неуправляемых языках.

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

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

> Да причем тут CLR? Что ты зациклился на CLR? Кто вобще говорит о CLR? Я
> уже раз 10 сказал что CLR не лучшая основа для управляемой ОС.
Просто я не вижу смысла обсуждать "абстрактный управляемый код в вакууме".

Здравствуйте, Cyberax, Вы писали:

>> Это очень сильно зависит от алгоритма и от оптамизатора.
C>Нет, к сожалению.
Те ты хочешь сказать что любой алгорит записанный в функциональном стиле будет очень сильно мусорить?

C>Ага, а тут у нас этот оверхед будет в софте.
Практика Сингулярити и простите ОберонОС показывают что этот оверхед ничтожен по сравнению с аппаратным который работает на уровне процессов... А что будет если железо будет контролировать каждый байт? Короче это будет называтся тушите свет.
C>_Сегодняшнее_ _х86-железо_ действительно ориентировано на процессы, однако ничего не мешает сделать более эффективную аппратную изоляцию.
Как ты собираешься делать защиту в железе на каждый объект? Надеюсь ты понимаешь что железу придется иметь дело с кучей метаинформации, и тупо проверять каждое действие с памятью? Причем никакие оптимизации не возможны в принципе.
А теперь сравни с программной изоляцией... во время компиляции можно сделать очень большое колличество проверок статически те устранить их или вынести за придела цикла...
Вобщем если делать все в железе то придется впаять большую кучу транзистеров на обеспечение безопасности. В то время как если делать программную изоляцию мы можем в место защиты которую может обеспечить софт сделать еще одно ядро которое можно задействовать для полезной работы.
Те мы теряем несколько процентов на проверках но выигрываем в два раза на том что у нас появляется еще одно ядро.

C>При этом теряя возможность использовать _любой_ небезопасный код в принципе.
А зачем он нужен? Что ты собрался делать такое что необходим не безопасный код?
Такой код как прекрасно показала Сингулярити нужен ТОЛЬКО в маленькой части ядра ОС. Ну и пусть он там будет. Ибо его очень мало и его пишут заведомо очень квалифицированные программисты.
А все что выходит за приделы микро ядра вполне может быть управляемым.

C>Переполнение буффера решается с помощью элементарной аппаратной защиты.
Где решается? Не вижу.

C>На многих архитектурах работает Windows XP?
По крайней мере на x86, x86-64, Intel Itanium. Это то о чем я знаю.
C>А RSDN@Home?
Он работает тамже где и WinXP. Единственное возможно придется пересобрать интероп.

А знаешь почему так мало архитектур? Нет не по тому что МС не модет портировать WinXP, а по тому что десятки тысяч других программ завязаны на x86. И их портирование практичеки не возможно ибо их писали кулхацкеры используя низкоуровневый небезопасный код.

C>Пусть остальные программисты пишут на .NET — я не против. Другое дело, что управляемые ОС _лишают_ возможности писать на неуправляемых языках.
ЗАЧЕМ?! Я не понимаю на кой черт тебе здались эти неуправляемые языки?

C>В последний раз наведенную ошибку в своем коде искал год назад.
Я тоже очень давно их не видел... даже когда писал на С++.
К томуже ты уверен что в твоих программах нет таких ошибок? Они ведь могут спать до поры до времени... Причем они могут быть не только в твоем коде но и в сторонней библиотеке... А могут появится при изменении версии библиотеки...
А в управляемых средах таких ошибок нет. Просто по тому что им неоткуда взятся...

C>И что-то мне подсказывает, что управляемость окажется не нужной.
Моя практика показывает что управляемость очень даже нужна...

C>Просто я не вижу смысла обсуждать "абстрактный управляемый код в вакууме".
Те ты просто взял плохой частный случай и обопщил его на все управляемый ОС? Это называется демагогия.

WolfHound wrote:
>> > Это очень сильно зависит от алгоритма и от оптамизатора.
> C>Нет, к сожалению.
> Те ты хочешь сказать что любой алгорит записанный в функциональном стиле
> будет очень сильно мусорить?
Почти весь.

> А что будет если железо будет контролировать каждый байт?
Счастье.

> C>_Сегодняшнее_ _х86-железо_ действительно ориентировано на процессы,
> однако ничего не мешает сделать более эффективную аппратную изоляцию.
> Как ты собираешься делать защиту в железе на каждый объект? Надеюсь ты
> понимаешь что железу придется иметь дело с кучей метаинформации, и тупо
> проверять каждое действие с памятью?
А что он сейчас делает, по-твоему, при работе со страничной памятью?

Фактически, для более fine-grained контроля нужно чтобы попытка
привиллегированой операции вызывало исключение. Это не так сложно —
механизмы линейных ACL давно перенесены в железо.

> Вобщем если делать все в железе то придется впаять большую кучу
> транзистеров на обеспечение безопасности.
Как раз подойдут те, которые сейчас занимаются эмуляцией Intel-8086

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

> C>При этом теряя возможность использовать _любой_ небезопасный код в
> принципе.
> А зачем он нужен? Что ты собрался делать такое что необходим не
> безопасный код?
Да. Мне необходим. Еще вопросы?

> C>Переполнение буффера решается с помощью элементарной аппаратной защиты.
> Где решается? Не вижу.
В старых добрых мейнфреймах Были процессоры, где на стек можно было
карту доступа ставить. Побайтную (точнее, пословную). Запись указателя
тоже была привиллегированой операцией.

> C>На многих архитектурах работает Windows XP?
> По крайней мере на x86, x86-64, Intel Itanium. Это то о чем я знаю.
И все они x86. За исключением Itanium, который все равно не сильно
отличается.

> А знаешь почему так мало архитектур? Нет не по тому что МС не модет
> портировать WinXP, а по тому что десятки тысяч других программ завязаны
> на x86. И их портирование практичеки не возможно ибо их писали
> кулхацкеры используя низкоуровневый небезопасный код.
Ага, а программы на .NET завтра магически смогут заработать на Alpha со
слабой архитектурой памяти.

> C>Пусть остальные программисты пишут на .NET — я не против. Другое дело,
> что управляемые ОС _лишают_ возможности писать на неуправляемых языках.
> ЗАЧЕМ?! Я не понимаю на кой черт тебе здались эти неуправляемые языки?
А ну быстро писать на Oberon! Зачем тебе остальные языки???

> C>В последний раз наведенную ошибку в своем коде искал год назад.
> Я тоже очень давно их не видел... даже когда писал на С++.
> К томуже ты уверен что в твоих программах нет таких ошибок? Они ведь
> могут спать до поры до времени... Причем они могут быть не только в
> твоем коде но и в сторонней библиотеке... А могут появится при изменении
> версии библиотеки...
Ну это уже параноя Мои программы обычно тестируются на тех
конфигурациях, где они будут использоваться.

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

> C>Просто я не вижу смысла обсуждать "абстрактный управляемый код в вакууме".
> Те ты просто взял плохой частный случай и обопщил его на все управляемый
> ОС? Это называется демагогия.
А еще какие управляемые среды вы можете привести в пример (кроме Java)?
Я вот знаю еще Parrot VM — но там нет верификатора (точнее не было,
когда я в последний раз смотрел).

Здравствуйте, WolfHound, Вы писали:

WH>Как ты собираешься делать защиту в железе на каждый объект? Надеюсь ты понимаешь что железу придется иметь дело с кучей метаинформации, и тупо проверять каждое действие с памятью? Причем никакие оптимизации не возможны в принципе.

afaik AS400 так работает.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

WH>>Как ты собираешься делать защиту в железе на каждый объект? Надеюсь ты понимаешь что железу придется иметь дело с кучей метаинформации, и тупо проверять каждое действие с памятью? Причем никакие оптимизации не возможны в принципе.
ANS>afaik AS400 так работает.
Те проводит статический анализ кода и устраняет не нужные проверки?

Здравствуйте, Cyberax, Вы писали:

C>Фактически, для более fine-grained контроля нужно чтобы попытка привиллегированой операции вызывало исключение. Это не так сложно — механизмы линейных ACL давно перенесены в железо.
Зачем это делать в железе если это можно сделать в софте? Причем в софте можно выкинуть большую часть проверок.

C>Как раз подойдут те, которые сейчас занимаются эмуляцией Intel-8086
Ага изменение набора комманд... те переписывание всего софта.

C>Нет, я даже могу набросать приблизительную схему такой защиты.
Давай. И за одно объясни как это будет работать для такого кода

void memcpy(void* dest, void const* src, int n)
{
    char* d = (char*)dest;
    char const* s = (char const*)src;
    char const* e = s + n;
    while(s != e)
        *d++ = *s++;
}

C>Да. Мне необходим. Еще вопросы?
Я не спрашивал тебя нужен тебе небезопасный код или нет. Я спрашивал зачем он тебе нужен.

C>В старых добрых мейнфреймах Были процессоры, где на стек можно было карту доступа ставить. Побайтную (точнее, пословную). Запись указателя тоже была привиллегированой операцией.
Те софт создавал карты доступа, а потом железо по этим картам работало? Так?

C>Ага, а программы на .NET завтра магически смогут заработать на Alpha со слабой архитектурой памяти.
А в чем проблема?

C>А ну быстро писать на Oberon! Зачем тебе остальные языки???
Сколько языков существует под .NET? А под жабу?
Причем тут вобще языки? Мы говорим об управляемых средах, а языки какбы дело десятое.

C>Ну это уже параноя Мои программы обычно тестируются на тех конфигурациях, где они будут использоваться.
Это не параноя. Это печальный опыт... Порой проблемы берутся просто изнеоткуда. Я в свое время занимался АСУТП и писал OPC серверы. Так вот была одна скада которая работала с другими серверами но при попытке подключится к моему она падала. Причем мой сервер проходил валидацию без замечаний и прекрасно работал со всеми другими скадами... Вобщем состыковать их так и не получилось. Хотя я долго и упорно пытался понять какже изменить мой сервер чтобы эта дура не падала...

C>Ага, там есть другие ошибки...
Какие? Только не говори про кодогенератор... Это всеравно что сказать что ошибки могут быть в железе... и они там действительно бывают... и чем сложнее железо тем болие вероятна ошибка... причем в отличии от софта который можно очень легко обновить с железом так поступить уже намного сложнее.

C>А еще какие управляемые среды вы можете привести в пример (кроме Java)?
А зачем? Му тут филосовствуем или где? Мы рассуждаем о том что лучше навороченая железка которая занимается всякой ерундой типа контроля кто куда пишет или простая железка которая ничего не проверяет но весть софт который на ней крутится проверен до запуска, а там где статика не дает ответа вставлены проверки.

WolfHound wrote:
> WH>>Как ты собираешься делать защиту в железе на каждый объект? Надеюсь
> ты понимаешь что железу придется иметь дело с кучей метаинформации, и
> тупо проверять каждое действие с памятью? Причем никакие оптимизации не
> возможны в принципе.
> ANS>afaik AS400 так работает.
> Те проводит *статический* анализ кода и устраняет не нужные проверки?
А зачем? У нас же быстрая аппаратная поддержка, с механизмом кэширования
вмонтированым в предсказатель переходов.

WolfHound wrote:
> C>Фактически, для более fine-grained контроля нужно чтобы попытка
> привиллегированой операции вызывало исключение. Это не так сложно —
> механизмы линейных ACL давно перенесены в железо.
> Зачем это делать в железе если это можно сделать в софте? Причем в софте
> можно выкинуть большую часть проверок.
Затем, что это не позволит писать софт ни на чем, кроме этого VM-языков.

> C>Как раз подойдут те, которые сейчас занимаются эмуляцией Intel-8086
> Ага изменение набора комманд... те переписывание всего софта.
А тут нам помогут технологии виртуализации — можно будет запустить тот
же софт в эмуляторе с JIT-транслятором x86. Вон у Apple'овцев вообще код
из PowerPC в x86 на лету транслируется всего с 50% потерей скорости в
Unreal Tournament 2004. Для этого эмулятора можно будет сделать
выделенный sandbox.

> C>Нет, я даже могу набросать приблизительную схему такой защиты.
> Давай. И за одно объясни как это будет работать для такого кода
> void memcpy(void* dest, void const* src, int n)
> {
> char* d = (char*)dest;
> char const* s = (char const*)src;
> char const* e = s + n;
> while(s != e)
> *d++ = *s++;
> }
При натыкании на указатель (слово с установленым старшим битом) — ошибка
защиты, выполнение микрокода, который проверяет может ли код с данным
значением IP делать модификацию указателей. И т.д.

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

Получается такой managed-assembler

> C>Да. Мне необходим. Еще вопросы?
> Я не спрашивал тебя нужен тебе небезопасный код или нет. Я спрашивал
> зачем он тебе нужен.
1. Скорость.
2. Гибкость.
3. А чем я хуже MS??

> Те *софт *создавал карты доступа, а потом железо по этим картам
> работало? Так?
Да. От переполнений буффера это спасает замечательно.

> C>Ага, а программы на .NET завтра магически смогут заработать на Alpha
> со слабой архитектурой памяти.
> А в чем проблема?
В слабой (weak) модели памяти. Сейчас ncNuma (non-cache-coherenet
Non-Uniform Memory Access) системы редки, но в будущем их ждет
распространие. Cell — это первый звонок.

> C>А ну быстро писать на Oberon! Зачем тебе остальные языки???
> Сколько языков существует под .NET? А под жабу?
> Причем тут вобще языки? Мы говорим об управляемых средах, а языки какбы
> дело десятое.
Ну да. У меня есть выбор:
1. VB.
2. C#.
3. Nemerle.

А где мой любимый C++ и Assembler (который не для MSIL)???

> Это не параноя. Это печальный опыт... Порой проблемы берутся просто
> изнеоткуда. Я в свое время занимался АСУТП и писал OPC серверы. Так вот
> была одна скада которая работала с другими серверами но при попытке
> подключится к моему она падала. Причем мой сервер проходил валидацию без
> замечаний и прекрасно работал со всеми другими скадами... Вобщем
> состыковать их так и не получилось. Хотя я долго и упорно пытался понять
> какже изменить мой сервер чтобы эта дура не падала...
А давайте я такую же слезливую историю расскажу про BEA Weblogic и
JBoss? Что характерно, оба на Java.

> C>Ага, там есть другие ошибки...
> Какие?
Молчаливое игнорирование исключений с разрушением логической структуры,
например. Скажешь редко бывает? Ну так и наведенные ошибки тоже редки.

Здравствуйте, WolfHound, Вы писали:

WH>>>Как ты собираешься делать защиту в железе на каждый объект? Надеюсь ты понимаешь что железу придется иметь дело с кучей метаинформации, и тупо проверять каждое действие с памятью? Причем никакие оптимизации не возможны в принципе.
ANS>>afaik AS400 так работает.
WH>Те проводит статический анализ кода и устраняет не нужные проверки?

Простите за двусмысленность. Там железная пообъектная защита. afaik

Дарней,

> C>Будут рулить вещи типа cell-архитектур для которых C# не подходит абсолютно и полностью. С++ тоже плохо подходит, правда.
>
> подозреваю, что как раз там будут рулить ФЯ

Может, и нет..

Здравствуйте, Cyberax, Вы писали:

C>Затем, что это не позволит писать софт ни на чем, кроме этого VM-языков.
А в чем проблема то? У меня складывается впечатление что баба Яга против! Тебя ведь не напрягает что тебе приходится писать только на языках компиляторы которых есть под данный процессор? Так в чем же тут проблема?

C>А тут нам помогут технологии виртуализации — можно будет запустить тот же софт в эмуляторе с JIT-транслятором x86. Вон у Apple'овцев вообще код из PowerPC в x86 на лету транслируется всего с 50% потерей скорости в Unreal Tournament 2004. Для этого эмулятора можно будет сделать выделенный sandbox.
Те предлагаешь сделать таки виртуальную машину... А почему бы не посадить все на одну виртуальную машину которая занимается тотальными проверками всего что можно?
Причем эта машина за счет оптимизатором сможет генерировать код который не в 2 раза медленней, а на несколько процентов.

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

C>Получается такой managed-assembler
Дык чем тебе нормальный управляемый ассемблер не нравится?

C>1. Скорость.
C>2. Гибкость.
C>3. А чем я хуже MS??
Хватит разводить демагогию. Ты на вопрос ответь: Какую задачу ты собираешься этим решать?

C>Да. От переполнений буффера это спасает замечательно.
А смысл? Если всеравно все держится на том что софт правильно заполнит таблици?

C>В слабой (weak) модели памяти. Сейчас ncNuma (non-cache-coherenet Non-Uniform Memory Access) системы редки, но в будущем их ждет распространие. Cell — это первый звонок.
Еще раз какие проблемы будут у управляемых сред с такими архитектурами? И почему ты думаешь что у С++ получится с ними лучше?

C>А где мой любимый C++ и
Блин ну напиши компилятор который будет генерировать код данной виртуальной машины если тебе так хочется попрограммировать на этом антиквариате. Вот тольк зачем если тотже немерле рвет С++ как тузик грелку?
C>Assembler (который не для MSIL)???
Это по определению не переносимо.

C>Молчаливое игнорирование исключений с разрушением логической структуры, например. Скажешь редко бывает? Ну так и наведенные ошибки тоже редки.
Вот только заглушенные исключения ловить намного проще чем чем порчу памяти 5-ого порядка.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>>>afaik AS400 так работает.
WH>>Те проводит статический анализ кода и устраняет не нужные проверки?
ANS>Простите за двусмысленность. Там железная пообъектная защита. afaik
Вот я не могу понять зачем нужна железная защита?
Cyberax похоже ушол в глухую демагогию может ты мне объяснишь чем проверки в железе лучше проверок в виртуальной машине? Ведь если не делать проверки в железе те вобще выбросить все транзисторы которые этим занимаются, а в место них просто добавить вычислительной мощьности то мы потеряем на проверках которые не смог устранить компилятор проценты но получим увеличиную мощь процессора. Плюс как я уже говорил чем сложнее процессор тем выше вероятность допустить ошибку в железе, а сменить железо гораздо труднее чем сменить софт.

Здравствуйте, WolfHound, Вы писали:

C>>Переполнение буффера решается с помощью элементарной аппаратной защиты.
WH> Где решается? Не вижу.
NX bit (AKA DEP)

WH>ЗАЧЕМ?! Я не понимаю на кой черт тебе здались эти неуправляемые языки?
Господа, после этой фразы вообще разговаривать дальше не о чем... Вы нас просто не можете понять.


Давайте завершим эту бесполезную дискуссию... Cyberax, сделай телевизор... погромче...

Здравствуйте, CreatorCray, Вы писали:

WH>>ЗАЧЕМ?! Я не понимаю на кой черт тебе здались эти неуправляемые языки?
CC>Господа, после этой фразы вообще разговаривать дальше не о чем... Вы нас просто не можете понять.
Я вижу только два места где умесны неуправляемые языки:
1)Ядро ОС. Причем очень не большая его часть.
2)Микрокод.
А вот теперь назови мне хоть одну причину по которой нужно использовать неуправляемые языке во всех остальных областях.

Здравствуйте, WolfHound, Вы писали:

WH> может ты мне объяснишь чем проверки в железе лучше проверок в виртуальной машине?

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

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>их нельзя обойти раз
Если ОС полностью управляемая и не грузит ничего что не может проверить то эту защиту тоже нельзя обойти.
К томуже даже аппаратной защите нужна метаинформация которую кто-то должен предоставить. Так что я не вижу каких либо преймуществ у аппаратного решения.
ANS>они достаточно низкоуровневые — два.
Не вижу смысла. Если код прошол валидацию ВМ которой извесно о коде все то зачем нам низкий уровень?
ANS>Что касается безопасности ВМ, то тебе Алексей уже говорил — технологии оптимизации, построенные на динамической генерации кода в эту модель не влазят.
Почему? Ведь код генерирует ВМ со всеми проверками.

WolfHound wrote:
> Cyberax похоже ушол в глухую демагогию может ты мне объяснишь чем
> проверки в железе лучше проверок в виртуальной машине?
Железо — оно _быстрее_, во-первых. Сколько тактов бы занял бы ручной
lookup указателя в memory map table, и сколько занимает его lookup для
железа процессора?

Во-вторых, железная защита позволяет продолжать использовать
unmanaged-приложения.

В-третьих, мы еще и получаем CAS (Code Access Security) в железе.

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

CreatorCray wrote:
> C>>Переполнение буффера решается с помощью элементарной аппаратной защиты.
> WH> Где решается? Не вижу.
> NX bit (AKA DEP)
Не совсем. Еще остается трюк jump-to-library, но уже достаточно близко.
Чтобы побороть j2l нужна защита указателей, в AS/400 сделано так:
1. Указатели отмечены специальным битом.
2. Для push'а адреса возврата используется специальная инструкция.
3. В стек кладется указатель со взведенным битом.
4. При попытке его изменения (кроме инструкции retn) — ошибка защиты.