机器码能否被转译为JVM字节码？为何相关转译方案十分少见？

这个方向不是完全没人做过，但从底层执行模型到工程落地全是绕不开的硬障碍，根本达不到“任意二进制在所有JVM环境跨平台运行”的预期，哪怕是仅依赖C标准库的极简程序也不例外，核心原因如下：

• 执行模型存在本质差异，转译性能损耗完全不可接受
  JVM字节码是为强类型、受控运行环境设计的栈式指令集：类加载阶段要经过字节码校验，操作数栈、本地变量都有明确的类型约束，控制流跳转的目标必须是合法的指令起始偏移，不允许随意修改执行指针、不允许把任意内存值当地址跳转执行代码。
  而x86/ARM等原生机器码是面向物理硬件的寄存器架构指令集：使用无类型平坦内存，支持动态计算地址任意跳转，允许运行时修改指令、把任意内存位置的数据当代码执行。要把这类指令转成能通过JVM校验的合法字节码，必须先在字节码层模拟出整套原生硬件环境：用大字节数组模拟虚拟内存、单独维护一组虚拟寄存器、模拟PC寄存器和CPU状态标志位，单条原生指令往往要对应十几到几十条操作虚拟硬件的字节码——本质就是用JVM字节码手写了一个全硬件模拟器，性能比原生代码低1~2个数量级都是乐观估计，甚至比QEMU这类成熟的本地模拟器还慢。
  举个最基础的例子，x86下一条add rax, rbx指令，转成字节码需要先从虚拟寄存器存储中取出两个寄存器的值，做加法后回写结果，还要同步更新溢出、零值、符号、进位等所有CPU状态标志，单条指令对应几十条字节码操作，就算JIT做极限优化也追不上原生执行效率。
• C标准库依赖远没有想象中轻量
  所谓“仅依赖C标准库”的程序，本质还是强依赖底层操作系统的系统调用：C标准库只是不同平台系统调用的封装层，Linux下编译的glibc程序对接Linux syscall表，Windows下编译的MSVCRT程序对接Win32/NT API，这些接口没有跨平台一致性。转成字节码后，要么针对每个目标平台单独做系统调用适配（那转出来的字节码根本不跨平台，完全违背最初的目的），要么在JVM里完整模拟一整套操作系统用户态运行环境——这个工程量和维护成本是天文数字，Wine、QEMU做了二十多年还没做到100%兼容性，在JVM上重写一套完全不现实。
  另外C语言存在大量未定义行为（类型双关、栈内存越界、动态计算函数指针跳转等），很多看起来简单的程序运行时也会依赖这些行为，而JVM的安全模型直接禁止这类操作，要兼容就只能继续在虚拟层做特殊处理，进一步拉低性能、提升复杂度。
• 机器码层面的转译存在无法补全的信息缺口
  编译完成的原生机器码已经丢失了几乎所有高层语义信息：函数边界、变量类型、控制流结构、代码和数据的区分都要靠反汇编算法推断，不存在100%准确的方案，遇到加壳、混淆的二进制基本直接失效。
  目前能在JVM上稳定运行原生代码的成熟方案（比如GraalVM LLVM运行时），全都是从高层中间表示（LLVM IR）直接编译为JVM可执行代码，根本不会处理最终产出的机器码——LLVM IR还保留了完整的类型、控制流、符号信息，转译难度比从机器码逆向低好几个量级，就算这样性能和兼容性也还是比原生代码差一截，只能覆盖特定场景。
• 落地场景下有性价比高得多的替代方案
  如果要在JVM环境调用原生代码，JNI/JNA直接调用本地二进制的方案已经非常成熟、性能足够好，根本不需要转字节码；如果要跨平台运行C/C++代码，要么直接用Java重写逻辑，要么把源码通过GraalVM直接编译到JVM平台，成本和效果都远好于转译已经编译好的机器码。

早年确实有项目尝试过这个方向，比如NestedVM就实现过MIPS二进制到Java字节码的转译，本质就是在JVM里实现了完整的MIPS模拟器和Unix系统调用翻译层，最终只能跑点对性能完全没要求的极简单小程序，根本没法大规模推广。现在不少Wasm到JVM字节码的转译工具体验比这个好，本质也是因为Wasm本身是带类型、控制流结构化、有明确隔离内存模型的中间表示，比无约束的原生机器码好转太多，就算这样性能也还是不如原生Java代码。
说白了，你设想的转译方案最终产出的就是个跑在JVM上的硬件+操作系统模拟器，性能差、兼容性差、开发维护成本极高，完全没有大规模落地的性价比。

内容的提问来源于stack exchange，提问作者PopKernel