Кажется, что все, что вы можете сделать с байт-кодом, вы можете делать так же легко и значительно быстрее в собственном коде. Теоретически вы можете даже сохранить независимость от платформы и языка, распределив программы и библиотеки в байт-коде, а затем скомпилируйте собственный код при установке, а не JITing.
Итак, в общем случае, когда вы хотите выполнить байт-код вместо native?
Хэнк Шиффман из SGI сказал (давным-давно, но до истины):
Существует три преимущества Java использование байтового кода вместо перехода к собственный код системы:
Портативность. Каждый компьютер имеет свою уникальную инструкцию задавать. Хотя некоторые процессоры включают инструкции для своих предшественников, в целом верно, что программа который работает на одном компьютере не будет работать ни на одном другом. Добавить в услуги, предоставляемые действующими системы, которые каждая система описывает в его собственный уникальный способ, и у вас есть проблема совместимости. В общем, вы не может писать и компилировать программу для один вид системы и запускать ее на любом другой без большой работы. Java получает вокруг этого ограничения путем вставки его виртуальная машина между приложения и реальной среды (компьютер + операционная система). Если приложение скомпилировано в Java-байт код и этот байт-код интерпретируется таким же образом в каждой среде, тогда вы можете написать одну программу, которая будет работать на всех платформы, на которых поддерживается Java. (Это теория, во всяком случае. практика всегда бывает небольшой несовместимости, лежащих в ожидании программист.)
Безопасность. Одной из достоинств Java является ее интеграция в Интернет. нагрузка веб-страницу, которая использует Java в вашем браузера и кода Java автоматически загружается и выполняется. Но что, если код уничтожает файлы, будь то злой или неряшливый на части программиста? Ява не позволяет загружать апплеты ничего разрушительного, запретив потенциально опасные операции. Прежде чем он сможет запустить код рассматривает его для попыток обойти безопасность. Он проверяет, что данные используется последовательно: код, который манипулирует элементом данных как целое число на одном этапе, а затем пытается использовать его как указатель позже будет пойман и не удалось выполнить. (Ява Язык не допускает указатель арифметика, поэтому вы не можете писать Java чтобы сделать то, что мы только что описали. Однако нет ничего, что могло бы предотвратить кто-то из написания деструктивного байта сам код с использованием шестнадцатеричного редактор или даже создание байта Java ассемблер кода.) Обычно это не возможно проанализировать программу машинный код перед исполнением и определить, делает ли оно что-либо Плохо. Трюки, как писать самомодифицирующийся код означает, что зло операции могут даже существовать до тех пор, пока позже. Но Java-код байта был разработан для такого рода проверки: это не имеет инструкций a вредоносный программист будет скрывать их нападение.
Размер. В мире микропроцессора RISC обычно предпочтительнее над CISC. Лучше иметь небольшой набор инструкций и использование многих быстрых инструкции выполнять работу, чем иметь многие сложные операции единичные инструкции. Проекты RISC требуют меньше ворот на чипе, чтобы выполнять свои инструкции, позволяя больше места для трубопроводов и других методы для каждой инструкции Быстрее. В интерпретаторе, однако, ничто из этого не имеет значения. Если ты хочешь реализовать единую инструкцию для оператор switch с переменной длина в зависимости от количества случаев статьи, нет причин не делать так. На самом деле сложный набор команд является преимуществом для веб- язык: это означает, что тот же программа будет меньше (меньше инструкции большей сложности), что означает меньшее время для передачи через нашу ограниченную скоростью сеть.
Поэтому, рассматривая байтовый код vs native, рассмотрите, какие компромиссы вы хотите сделать между переносимостью, безопасностью, размером и скоростью выполнения. Если скорость является единственным важным фактором, идите на родной язык. Если какой-либо из них более важен, перейдите к байт-коду.
Я также добавлю, что поддержка серии OS и архитектурных целевых компиляций одной и той же базы кода для каждой версии может стать очень утомительной. Это огромная победа в использовании одного и того же байт-кода Java на нескольких платформах и "просто работайте".
Производительность по существу любой программы улучшится, если она будет скомпилирована, выполнена с профилированием, а результаты будут возвращены в компилятор для второго прохода. Фактически используемые пути кода будут более агрессивно оптимизированы, петли будут развернуты до нужной степени и горячие пути команд, чтобы максимизировать хиты я $.
Все хорошие вещи, но это почти никогда не делается, потому что это раздражает пройти через так много шагов, чтобы построить двоичный файл.
Это преимущество выполнения байт-кода на некоторое время перед его компиляцией на собственный код: информация профилирования автоматически доступна. Результатом после компиляции Just-In-Time является высоко оптимизированный собственный код для конкретных данных, которые обрабатывает программа.
Возможность запуска байт-кода также обеспечивает более агрессивную собственную оптимизацию, чем статический компилятор может безопасно использовать. Например, если один из аргументов функции отмечен всегда равным NULL, вся обработка для этого аргумента может быть просто исключена из собственного кода. Будет кратковременная проверка достоверности аргументов в прологе функции, если этот аргумент не равен NULL, ВМ вернется к байт-коду и снова начнет профилирование.
Bytecode создает дополнительный уровень косвенности.
Преимущества этого дополнительного уровня косвенности:
Некоторые из недостатков:
Все хорошие ответы, но моя горячая кнопка была поражена - производительность.
Если выполняемый код тратит все свое время на вызов библиотечных/системных подпрограмм - операции с файлами, операции с базой данных, отправка сообщений в Windows, то это не имеет особого значения, если он JITted, потому что большая часть часов времени проводится в ожидании эти операции нижнего уровня для завершения.
Однако , если код содержит вещи, которые мы обычно называем "алгоритмами", которые должны быть быстрыми и не тратить много времени на вызов функций и, если они используется достаточно часто, чтобы быть проблемой производительности, тогда JIT очень важен.
Думаю, вы просто ответили на свой вопрос: независимость платформы. Независимый от платформы байт-код создается и распространяется на целевую платформу. При выполнении он быстро компилируется в собственный код либо до начала запуска, либо одновременно (Just In Time). Java JVM и, предположительно, время выполнения .NET работают по этому принципу.
Здесь: http://slashdot.org/developers/02/01/31/013247.shtml
Пойди, посмотри, что скажут об этом вундеркинды Слэшдота! Маленькие датированные, но очень хорошие комментарии!
В идеале у вас будет переносимый байт-код, который компилирует Just In Time в собственный код. Я думаю, что причина, по которой интерпретаторы байт-кода существуют без JIT, объясняется прежде всего практическим фактом, что компиляция собственного кода добавляет сложности виртуальной машине. Для создания, отладки и поддержки этого дополнительного компонента требуется время. Не все имеют время или ресурсы, чтобы сделать это.
Вторичным фактором является безопасность. Гораздо проще проверить, что интерпретатор не будет терпеть крах, чем гарантировать то же самое для собственного кода.
В-третьих, это производительность. Часто может потребоваться больше времени для генерации машинного кода, чем для интерпретации байт-кода для небольших фрагментов кода, которые выполняются только один раз.
Переносимость и независимость платформы, вероятно, являются наиболее заметными преимуществами байт-кода над собственным кодом.