Каковы недостатки нацеливания на JVM вместо x86?

Question

Я разрабатываю новый язык. Моей первоначальной целью была компиляция на родной x86 для платформы Windows, но теперь я сомневаюсь.

Я видел несколько новых языков, нацеленных на JVM (наиболее известные Scala и Clojure). Конечно, невозможно перенести каждый язык легко в JVM; это может привести к небольшим изменениям в языке и его дизайне.

После постановки этого вопроса я даже больше сомневался в этом решении. Теперь я знаю некоторые «про» аргументы JVM. Первоначальный вопрос был: хорошая идея для JVM при создании компилятора для нового языка?

Обновлен вопрос: Каковы недостатки нацеливания на JVM вместо x86 в Windows?

Answer 1

Возможно, вы захотите взглянуть на таргетинг на LLVM вместо JVM. LLVM может использоваться для целевого ряда архитектур, включая x86.

Переносимость - это больше, чем просто поддержка ЦП, но LLVM может сильно помочь и, если хотите, все равно даст вам собственный код.

Answer 2

Ориентация на JVM - довольно проверенный и проверенный подход. Тот факт, что Clojure, Scala, JRuby и многие другие языки сделали это успешно, должен вас обнадежить.

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

Сказав это, основные недостатки, с которыми вы можете столкнуться при нацеливании на JVM, заключаются в следующем:

• Отсутствие поддержки хвостовой рекурсии на уровне байт-кода. Есть способы обойти это (например, см. Специальную форму «повторения» Clojure), но это раздражает для некоторых языковых реализаций, особенно для функциональных языков. Возможно, в конечном итоге будет исправлено в будущих версиях Java.

• Немного очевидно, но вам нужна JVM, установленная на вашем клиенте. Обычно в наши дни это не проблема, но есть случаи, когда это может быть сложно.

• Примитивы (int, long, float и т. Д.) В Java ведут себя иначе, чем остальная часть объектной системы. Опять же, вы можете обойти это, но это немного хлопотно для разработчиков языка.

Некоторые потенциально полезные / интересные ссылки:

• ASM-структура анализа и обработки байт-кода . Это отличный инструмент, Я считаю, что именно это использует Clojure под капотом.

• Исходный код Clojure

Answer 3

Если вы создаете язык для JVM, у вас также есть большое преимущество в том, что у ваших ног огромная библиотека, которую можно легко использовать из вашего языка. Скорее всего, это не тот случай, если вы компилируете для x86. Я предполагаю, что вы не сможете включить, например, Заголовки C на вашем языке без синтаксического анализатора C.

По этой причине Scala, Groovy и другие имеют такой успех.

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

Answer 4

Вы должны ориентироваться на JVM только в том случае, если вы довольны тем, что часть времени выполнения вашего кода полностью зависит от кода стороннего производителя и требует от пользователей установки таких кодов, и , что JVM предоставит существенные функции что вы не можете разумно разрабатывать себя или просить людей расширять для этой цели (например, заголовки ОС в C ++), и , вы довольны JNI как интерфейсом к нативному коду (и, таким образом, другим управляемый код, например .NET).

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