Мне тоже интересно, по моей памяти jit запускался после байт кода, хотя что-то могло и измениться. Конечно в Java есть и способы манипуляции байт кода, но это не самый распространённый сценарий.

ну смотрите, перевели вы java bytecode в wasm, запускаете, а JITа нету, wasm код переведется в бинарный код и больше не будет оптимизироваться. В случае JVM, как уже говорил @GabrielFallen для сгенерированного кода будет проводится много оптимизаций, нажиная от constant propogation, до спекулятивных оптимизаций, escape анализа и scalar replacement

Вы тут смешиваете несколько уровней трансляции в одну кучу. Не смотрел, что там конкретно делают сейчас, но, понятное дело, можно компилировать в Wasm именно байт-код, а можно и сам Java-исходник без байт-кода. Результаты будут отличаться. Это раз.

Во-вторых, сам итоговый Wasm-код может исполняться 3 способами: интерпретироваться, компилироваться в бинарник AOT или JIT. На текущий момент, Wasm-JIT-компиляторы работают "в одну сторону" — не делают спекулятивных оптимизаций и деоптимизаций, соответственно. Ну и профилирования тоже не делают за ненадобностью. Однако! Принципиально ничего не мешает им начать этим заниматься в будущем, когда в Wasm завезут фичи, которые могут от этого выиграть.

Так вот, примерно все оптимизации, которые Вы перечислили, могут выполняться как компилятором Java->Wasm, так и Wasm-JIT/AOT. 😊 А вот спекулятивных девиртуализации и инлайнинга уже не будет, например...

мы от JITа все больше отказываемся в пользу AOT. но у нас и язык эволюционирует в попутном направлении, да и iOS заставляет... поэтому с WASMом нам проще сегодня, чем было скажем 3 года назад. на мой взгляд самая интересная комбинация это какие-то гибридные модели (AOT + динамическая компиляция)

Да, я понимаю. Но часть оптимизаций спекулятивные по построению и могут быть выполнены только в рантайме, как упомянутая девиртуализация + инлайнинг. И в ОО-коде она даёт очень заметный кусок производительности. Видимо, это и имеется в виду под AOT + динамическая компиляция. Я вот думаю, сможет ли JIT для Wasm в будущем взять это на себя? 🤔

девиртуализацию можно и не спекулятивную делать и мы делаем за счет глобального анализа типов - достаточно важная оптимизация в AOT для языков с большим количеством непрямых вызовов (как Java и Dart)... а можно и спекулятивную девиртуализациию делать в AOT, но там возникают, конечно, вопросы - если fallback не отсекать, то как оптимизировать?

(для современных CPU важна чаще всего не сама девиртуализация, а последующие оптимизации.)

а что у вас за продукт?

в WASM я какое-то время агитировал Андреаса и Бена за invokedynamic. Но мне кажется они думали что я их трололо

Dart VM

спс

Понятно, что её и для C++ делают AOT как могут. Технически, для Java AOT можно только очень ограниченно, потому что там есть Class Loader. Конечно, если в Wasm его не тащить, то можно больше. У Dart такой проблемы нет?

То-то и оно...

Там же и так есть вызовы по индексам... 🤔

Да для Java нужно предоставлять fallback для случая если код загружен кустомным classloaderом (e.g. JIT or interpreter), либо накладывать ограничение что custom classloaders не используются, либо специально поддерживать определенные custom classloaders в компиляторе. У меня магистерская диссертация была на эту тему: "Поддержка OSGi на уровне виртуальной машины Java". Мы за счет этого JETом (пусть ему земля будет пухом) могли Eclipse based приложения компилировать, а потом еще Tomcat classloaders поддержку добавили.

В Dart такой проблемы к счастью нет. (spawnUri мы в AOT приложениях запрещаем)

invokedynamic это не только кастомное динамическое связывание (которое можно эмулировать через function pointer и их эквиваленты), но и специальная поддержка со стороны VM - которая как раз и позволяет выразить такие вещи как спекулятивную девиртуализцию даже при компиляции языков со сложными dispatch механизмами. (там можно допустим связать call-site с целью вызова, а потом если что поменялось пересвязать его опять).

Подозреваю, это изрядно противоречит таким ценностям Wasm как safety и predictability... 😒

Надеюсь, они сильно отступятся от детерминизма выполнения, потому что почти все реально нужные фичи его не предполагают.

плюс в браузерах все больше и больше multitiered runtimы используются для WASM.