Каковы некоторые фундаментальные особенности/архитектурные различия между BEAM и JVM?
Во-первых, Beam — это регистровая машина, а не стековая. Как и WAM для Пролога, он использует «X-регистры», которые представляют собой обычные регистры (реализованные в виде массива в C), и «Y-регистры», которые являются именами слотов в локальной записи активации функции («кадр вызова»). в стеке. Инструкций по работе со стеком нет.
Во-вторых, есть инструкции для быстрого выделения еще нескольких слов памяти кучи, для инициализации кортежей и других структур данных в куче, для выбора элементов кортежей и т. д. JVM ориентирована на объекты и имеет «новую» операцию, которая скрывает детали распределения памяти и базовой инициализации.
В BEAM есть инструкция для уменьшения «счетчика сокращения» для процесса и принятия решения о том, пора ли уступить, чтобы позволить запуститься другому процессу. JVM, с другой стороны, имеет инструкции по синхронизации для потоков.
Одно важное отличие состоит в том, что BEAM имеет инструкции хвостового вызова, которых нет в JVM.
Наконец, как для BEAM, так и для JVM набор инструкций, используемый в объектных файлах, на самом деле является только транспортным форматом. Эмулятор BEAM переписывает инструкции из файла во внутреннюю версию с множеством оптимизированных инструкций для особых случаев (которые могут меняться от одной версии к другой). Кроме того, вы можете скомпилировать собственный код. Большинство JVM делают то же самое.
Некоторые другие интересные моменты:
Процессы являются гражданами BEAM и управляются самой виртуальной машиной, в то время как JVM делегирует свое управление ОС. Это позволяет BEAM управлять (создавать, удалять, переключать контекст и т. д.) очень быстро и, таким образом, иметь возможность управлять сотнями тысяч процессов по сравнению с несколькими сотнями потоков Java на разумной машине.
В BEAM межпроцессное взаимодействие основано на обмене сообщениями, что устраняет большинство, если не все ситуации, которые могут привести к состоянию гонки. В Java вам нужно синхронизировать потоки, что сложно и подвержено ошибкам.
Одним из важных моментов является то, что сборка мусора выполняется для каждого процесса в BEAM, в то время как в JVM это глобальный процесс. Влияние заключается в том, что GC на JVM может заморозить всю VM, возможно, на несколько секунд, в то время как на BEAM каждый процесс должен передать некоторые из своих операций выполнения (сокращения) GC без влияния на другие процессы.
В последнее время некоторые новые библиотеки, такие как VertX (на самом деле я не знаю, Akka, но я считаю, что это так) для языков JVM начали реализовывать аналогичное поведение процессов, чтобы попытаться решить проблемы 1. и 2. Я считаю, что проблема GC однако не может быть решена просто с библиотекой.
