BEAM 和 JVM 之间有哪些基本功能/架构差异？
BEAM 和 JVM 之间有哪些基本功能/架构差异？
- 是的，我知道：一个最初是围绕 java 构建的，另一个是围绕 erlang 构建的
- 我（在某种程度上）了解 JVM，并想比较它们的结构
- 例如，我知道 JVM 有一个全局 GC，而 BEAM 每个进程有一个
What are some fundamental Feature/Architectural difference between the BEAM and JVM?
- Yes I know: one was originally built around java and the other built around erlang
- I understand the JVM (somewhat) and want to compare their structures
- For example I know that the JVM has one Global GC and BEAM has one per process
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
首先，Beam是寄存器机，而不是堆栈机。与 Prolog 的 WAM 一样，它使用“X 寄存器”，它们是普通寄存器（在 C 中实现为数组），以及“Y 寄存器”，它们是本地函数激活记录中的槽的名称（“调用帧”）在堆栈上。没有堆栈操作指令。
其次，有一些指令用于快速分配更多字的堆内存，用于初始化堆上的元组和其他数据结构，用于选择元组的元素等。JVM专注于对象，并且有一个隐藏的“new”操作内存分配和基本初始化的详细信息。
BEAM 有一条指令，用于递减进程的“减少计数器”并决定是否是让出让另一个进程运行的时间。另一方面，JVM 有线程同步指令。
一个重要的区别是 BEAM 具有 JVM 所缺乏的尾部调用指令。
最后，对于 BEAM 和 JVM 来说，目标文件中使用的指令集实际上只是一种传输格式。 BEAM 模拟器将文件中的指令重写为内部版本，其中包含许多优化的特殊情况指令（可以从一个版本更改为另一个版本）。或者，您可以编译为本机代码。大多数 JVM 都做同样的事情。
First of all, Beam is a register machine, not a stack machine. Like the WAM for Prolog, it uses "X-registers" which are normal registers (implemented as an array in C), and "Y-registers" which are names for slots in the local function activation record (the "call frame") on the stack. There are no stack manipulation instructions.
Second, there are instructions for quickly allocating a few more words of heap memory, for initializing tuples and other data structures on the heap, for selecting elements of tuples, etc. JVM is focused on objects, and has a 'new' operation that hides the details of memory allocation and basic initialization.
The BEAM has an instruction for decrementing the "reduction counter" for the process and deciding whether it is time to yield to let another process run. JVM on the other hand has synchronization instructions for threads.
One important difference is that BEAM has tail call instructions, which JVM lacks.
Finally, for both the BEAM and JVM, the instruction set used in object files are really only a transport format. The BEAM emulator rewrites the instructions from the file into an internal version with many optimized special-case instructions (that can change from one release to another). Alternatively, you can compile to native code. Most JVMs do the same thing.
其他一些有趣的点是：
进程是 BEAM 公民，由 VM 本身管理，而 JVM 将其管理委托给操作系统。这使得 BEAM 能够非常快速地管理（创建、删除、上下文切换等），因此能够在合理的机器上管理数十万个进程，而不是数百个 Java 线程。
在 BEAM 上，进程间通信基于消息交换，这消除了大多数（如果不是全部）可能导致竞争条件的情况。在 Java 上，您需要同步线程，这是困难且容易出错的。
一个重要的一点是，垃圾收集是在 BEAM 中以每个进程为基础完成的，而在 JVM 中它是一个全局进程。其影响是，JVM 上的 GC 可能会冻结整个 VM 几秒钟，而在 BEAM 上，每个进程必须将其部分执行操作（减少）交给 GC，而不影响其他进程。
最近，一些新的库，例如 VertX （我真的不知道Akka 但我相信是这样的）JVM语言开始实现类似的进程行为来尝试解决问题1.和2。我相信GC的问题不能被解决不过，可以通过库简单地解决。
Some other interesting points are:
Processes are BEAM citizens and are managed by the VM itself while the JVM delegates their management to the OS. This allows the BEAM to manage (create, delete, context switch, ...) very quickly and, thus, to be able to manage hundreds of thousands of processes versus few hundreds of java threads on a reasonable machine.
On BEAM, inter-process communications is based on message exchange which eliminates most if not all situations which may lead to a race condition. On Java, you need to synchronize threads which is difficult and bug prone.
One important point is that garbage collection is done on a per process basis in the BEAM while it's a global process in the JVM. The impact is that a GC on the JVM may freeze the whole VM for possibly some seconds while on the BEAM each process has to give some of it's execution operations (reductions) to the GC without impact on the other processes.
Recently, some new libraries like VertX (I don't really know Akka but I believe it's the case) for JVM languages began to implement similar process behaviours to attempt to solve issues 1. and 2. I believe the problem of the GC cannot be solved with simplicity with a library, though.