«Есть более эффективные способы описания семантики, чем байт-коды Java»?

Question

Клифф Нажмите, в своей речи «А JVM ли это?», Говорит: «Есть более эффективные способы, чтобы описать семантику, чем Java байт-код»: http://www.youtube.com/watch?v=uL2D3qzHtqY&t=8m55s

Почему? В чем проблемы с байт-кодом Java? Каковы альтернативы?

Answer 1

Bytecode уже теряет довольно много семантики, вот в чем проблема. Это своего рода неструктурированный машинный код. В качестве примера можно увидеть огромную сложность декомпилятора Java: это в основном C.S.I. команда Java, кропотливо восстанавливая исходный код из фрагментов информации, разбросанных по байт-коду.

Поскольку современные JVM не очень полезны для байт-кода, кроме как описания семантики программы, она утратила свою первоначальную цель, которая должна была быть относительно быстро интерпретируемым форматом, промежуточным по уровню описания между Java и собственным машинным кодом.

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

int i = 0; 
String s = ""; 
for (Integer num : nums) { 
    s += num; 
    if (++i < ints.size()) s += ", "; 
} 

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

1. с использованием неизменяемого типа String для хранения промежуточных значений через петлю;
2. , поддерживающий отдельную индексную переменную, i, которая является дубликатом той, которая хранится в неявной Iterator;
3. проверяет i на размер списка каждый раз, хотя ясно, что это будет верно только на последней итерации.

JIT-компилятор обычно выполняет цикла специализации Оптимизационный: он будет издавать отдельный код только для последнего шага петли, тем самым полностью исключает повторное if проверки.Он также может понять, что промежуточные строки не ускользают и автоматически заменяют всю идиому на StringBuilder.

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

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

Answer 2

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

В этом контексте: Он говорит о том, что абстрактное определение Java заключается в том, что байт-коды интерпретируются, а интерпретация байт-кодов - очень медленный процесс. Но «под обложками» Java использует JIT-компилятор - и в JIT-приложениях hotspot использует профилирование производительности для выполнения более сложных оптимизаций - для «создания иллюзии», которые быстро работают байт-коды.

Если вы разрабатываете новое поколение Java-сред, операционных систем или языков, то эти различия имеют значение.

Но, что касается большинства людей, это не имеет смысла, чем тот факт, что современные процессоры перекрывают выполнение некоторых инструкций. Большинство людей не думают о бат-кодах вообще, не зная, что они представляют собой переносимое представление кода. Они компилируют Java. Они загружают его в свою JVM. Он работает на разумной скорости. Готово.