将 jvm 移植到内核空间？

Question

目前我正在考虑在内核空间中运行 jvm 作为（也许是 linux）内核模块的想法。我看到了这个想法的很多优点。

当然，这种系统的最大优点是内核空间开发的主要简化。但它的发生是因为不同的方面：

1）每个具有相对次要低级知识的Java开发人员都能够开发内核模块。是的，这肯定不是一个很好的可能性:-)，特别是如果我们看到大多数开源 Java 用户空间项目的当前代码质量，但是......在内核空间中也没有必要发生同样的事情。

2）（也是真正的目标）：JVM可以解决内核开发最大的问题，就是内存保护的缺失。如果没有其他问题（fe jit 编译器错误或低级硬件问题），从 java 编译的二进制代码段从未对超出其范围的数据结构造成任何损害，尽管此类二进制代码的运行时安全检查导致了速度上的可衡量缺陷。

首先，它也不需要是一个 java 字节码解释器。JIT（即时编译器）可以存在于系统用户空间中，仅映射内核空间中已编译的二进制文件（实际上：内核模块）。只有命名空间管理器和垃圾收集器需要在内核空间中运行。

其次，它不需要大、慢和可怕。这是因为在用户空间 jvms 的情况下使用大的、无效的库，并且在例如用 java 编写的驱动程序的情况下没有相同的理由。

我能看到的唯一后备是实时功能。当然，用 java 来做要困难得多，因为我们对内存管理的次要细节的控制要少得多。

我很好奇，如果这样的项目已经存在（？#1），并且如果没有（？#2），是否有任何明显的主要回退。

Answer 1

我认为这将是一个非常大的项目，因为您需要使用内核 API 用C 语言编写的带有自定义部分的 JVM 实现。openjdk 热点在 C 和 C++ 中显然是 250K+ LOC。请注意，您不能在 linux 内核中使用 C++。

我认为这可能需要几个人年才能实施。您不太可能将它包含在官方源代码树中，但这并不是什么大问题。

考虑到与您所说的“最大优势”相关的规模：

当然，这种系统的最大优点是内核空间开发的主要简化。

我不确定你的意思是什么。对于会用 Java 编码但不会用 C 编码的人，我想这显然是正确的。但如果你的意思是一般意义上的，我不明白那会是怎样。我对 C 和 Java 都感到满意，并且对其中一个没有强烈的偏好（上下文或其他人往往会为我做出这个决定）。也许 Java 更容易使用，因为，例如，你不需要做 MM（但 MM 真的那么难吗？）等等——但 IMO 也可能看起来更尴尬和受限制。

就我个人而言，我不会认为这是一个值得追求的事情，但这并不意味着我认为这是不可能的，或者是一个坏主意。您的主要障碍将是寻找其他人做出贡献。