Google-воды явно понимают, что если все приложения для их Chromium OS будут писаться на JavaScript, то ничего хорошего из этого не выйдет. Поэтому они активно развивают NativeClient – инструмент для запуска нативного кода внутри браузера. Т.е. часть Web-приложения пишется на JavaScript, а часть – на C/C++. И нативная часть работает через NativeClient, что должно обеспечивать должную скорость и безопасность.
Если мне не изменяет мой склероз, первые версии NativeClient были очень ограничены по функциональности. Но со временем они стали позволять C/C++ программистам делать все больше и больше.
На днях Google выпустил очередную бета версию своего NativeClient SDK. Похоже, что NativeClient превращается в эдакий гипервизор для нативного кода. При полученном на тестах падении производительности в 3% обеспечивается высокий уровень безопасности: разработчикам доступен только ограниченный набор API-шных вызовов для взаимодействия с системой + к тому NativeClient контролирует выход за пределы отведенной нативному коду памяти.
Такими темпами из NativeClient может получиться практически виртуальная машина для C/C++. Особенно учитывая планы по подтягиванию к этому делу LLVM. Тогда вообще можно будет получить систему a la Java – С++ные приложения транслируются в LLVM-овский байт-код, который и передается на сторону клиента. Там он транслируется в нативный и исполняется с максимальной скоростью.
Опять же, если доверять моему склерозу, то Михаэль Франц, ученик Никлауса Вирта, когда-то критиковал Java за то, что там не было сделано именно так. Первые Java были интерпретаторами, HotSpot появился позднее. А Франц, помнится, тогда разработал для Компонентного Паскаля похожий подход – код транслировался в высокоуровневое бинарное представление, которое было кроссплатформенным. На конкретной платформе это представление специальными оптимизированными под платформу/архитектуру компиляторами транслировалось в машинный код. Причем вся эта кухня к моменту появления первых версий Java уже работала.
6 комментариев:
Есть какие-нибудь подробности по подключению к NaCl LLVM?
Гугл выдает вот эту ссылку: http://nativeclient.googlecode.com/svn/data/site/pnacl.pdf
Сам я никогда NaCl никогда вблизи не смотрел, просто читаю новости о нем.
к тому NativeClient контролирует выход за пределы отведенной нативному коду памяти
Самое главное, чтобы в системе контроля не было допущено уязвимостей. Слышал, что в Java часто исправляли уязвимости, связанные с возможностью повышения привилегий и выхода за дозволенные границы.
Женя, ты чуток народ вводишь в заблуждение. LLVM вообще не нужно было упоминать, да и Java тоже. NativeClient работает таким образом: бинарник (!!!) заливается по сети и проходит через очень маленький (по объему и функционалу) плагин браузера, который один раз проверяет бинарник на безопасность и отдает его на выполнение в процессор. Безопасность обеспечивается тем, что код проверки очень небольшой (код этого плагина браузера) в отличие от Явы. Кроме того, на код наложены жесткие ограничения: сегмент кода выполняется, но не пишется, данные пишутся, но не выполняются, команды косвенных переходов очень ограничены, команды выровнены по определенной границе (для гарантии дизассемблирования). Таким образом, в коде безопасности ошибки вычистят очень быстро (это не 30М ява машыны с библиотеками, это несколько килобайт плагина к браузеру) и этот код гарантирует, что то что он запустит после однократной проверки не сделает чего-нибудь неправильного. Выполняемый код работает на процессоре напрямую и общается только с API NativeClient.
Разработчики, во-первых, отказались от всяких jit, во-вторых, от монстроидальных оболочек, обеспечивающих безопасность (при этом дырявых, т.к. в них слишком много кода, чтобы вычистить в нем ошибки).
Код для выоплнения генерит модифицированный GCC, который делает нужное выравнивание команд и не генерит разных косвенных переходов.
Подробности тут (на русском с картинками)
http://www.youtube.com/watch?v=Oknm3_82Pc0
Обсуждение тут
http://www.linux.org.ru/news/opensource/4884022
2san: в ответе на комментарий тов.gp я дал урл на PDF-ку, в которой показано, каким образом в NaCl используются наработки LLVM. Данная тобой ссылка на доклад датируется декабрем 2009, упомянутая мной PDF-ка февралем 2010. Думаю, за это время Google несколько пересмотрел свою технологию.
А за объяснение принципа работы NaCl спасибо.
Поправочка: даже не декабрем 2009, а ноябрем 2009.
Отправить комментарий