2

Currently I am playing with the idea of a jvm running in the kernel space, as a (maybe linux) kernel module. I see a lot of advantage of the idea.

Of course the biggest advantage of a such system were the major simplification of the kernel space development. But it happened because different aspects:

1) every java developer with a relative minor lowlevel knowledge were able to develop a kernel module. Yes, it is't surelly a good possibility :-), especially if we see the current code quality of most opensource java userspace projects, but... there isn't a need to happen the same in the kernelspace as well.

2) (And it is the really intended goal): a JVM could solve the greatest problem of the kernel development, and it is the lack of the memory protection. A binary code segment compiled from java never caused any harm to data structures out of its scope, if there isn't another problem (f.e. jit compiler error or lowlevel hw problem), although the runtime safety checks of a such binary code caused a well measurable drawback in speed.

First, it doesn't need to be a java bytecode interpreter as well. A JIT (just in time compiler) could exist on the system user space, mapping only the compiled binary files (practically: kernel modules) in the kernel space. Only the namespace manager and the garbage collector need to run in kernel space.

Second, it doesn't need to be big, slow and monstrous. It is because the big, ineffectively used libraries in the case of the userspace jvms, and there is no ground for the same in case of, for example, a driver written in java.

The only fallback which I can see were with the realtime functionality. Of course it were much harder to do with java, because we have much fewer control on the minor details of the memory management.

What about I am curious, if a such project already exists (?#1), and are there any visible major fallbacks about this if not (?#2).

10
  • 2
    Search for "java OS", this has been done before. Not very successfully AFAIK. As for memory protection, search for "micro kernels", this also exists already.
    – Mat
    May 26, 2014 at 11:39
  • 1
    @Mat JavaOS was a complete OS, it were only a kernel extension. JavaOS didn't contained jit, my idea is based on a jit. Imho JavaOS had much more with android to do as to my idea. About memory protection: memory protection of the microkernels is based on paging or swapping, so MMU memory protection, which does the actual protection actively, in runtime. The memory protection of a such system happened mostly in compile-time.
    – peterh
    May 26, 2014 at 11:49
  • MMUs are in the hardware on current general purpose CPUs, trying to do the same thing in software would is much more costly. Memory protection is fundamentally a runtime issue. Using only AOT (ahead of time) compiler rather than a JIT removes a lot of the advantages of having a JIT. Android, AFAIK, doesn't have Java in its kernel.
    – Mat
    May 26, 2014 at 12:04
  • @Mat The memory protection in the jvm works very differently (for example, it runs mostly in runtime and not in compile time) as the paging/swapped based of the MMUs, measuring them in the others reference frame gives unusable result. Memory protection is not surely a runtime issue, even if it happens mostly in the current systems (f.e. you can use a language with them only a correct program can be compiled - a such system can eliminate most of the need for an MMU).
    – peterh
    May 26, 2014 at 12:16
  • @Mat "Android, AFAIK, doesn't have Java in its kernel." <- and this is because my idea has nothing to do either of them. JavaOS and Android are a complete change of the old unix userspace, and this is what killed javaos and one of the greatest trouble source of the current Android as well, and this is what also you thought, although I mentioned exactly that I am talking only about a kernel ported jvm and not about a completely new system.
    – peterh
    May 26, 2014 at 12:17

2 Answers 2

6

I think this would be a very big project, since you would need a JVM implementation written in C with custom parts using the kernel API. The openjdk hotspot is apparently 250K+ LOC in C and C++. Note you cannot use C++ with the linux kernel.

Methinks that could work out to a number of person-years to implement. It's very unlikely you could then get it included in the official source tree, but that is not such a big deal.

Considering that scale in relation to what you refer to as "the biggest advantage":

Of course the biggest advantage of a such system were the major simplification of the kernel space development.

I'm not sure what you mean by this. For people who can code in Java but not C, I suppose this is obviously true. But if you mean in a general sense, I don't see how that would be so. I'm comfortable with both C and Java and don't have a strong preference for one over the other (context, or someone else, tends to make this decision for me). Perhaps Java is slightly easier to use since, e.g., you don't need to do MM (but is MM really that difficult?), etc. -- but IMO it can also seem more awkward and restricted.

Personally, I would not consider this a worthwhile pursuit, but that does not mean I think it is impossible, or a bad idea. Your major hurdle will be finding other people to contribute.

4

Having in-kernel JVM doesn't really seem to solve much. While it's true, that the lack of pointers provides reasonable isolation of independent pieces of code it would also pull in either Java bytecode interpreter (which is permanently slower than native code) or a JIT compiler (which is extremely slow at the beginning). And I'm not mentioning the garbage collector, which I suspect you might be hoping to automagically solve some problems (which it won't).

Another problem to solve would be interfacing any hardware. You would need a rather non-trivial piece of code that would allow the Java code to access e.g. network card, SATA, (i)SCSI, USB, FibreChannel and myriads of other controllers, audio card and (one of the more tricky bits, I suppose) a graphic accelerator. This would lead to a substantial piece of code being written in another language closer to bare metal (be it assembly or C/C++ - which actually is not much more, than a more readable assembly with higher level of abstraction).

In the end if, writing kernel code in Java was the ultimate goal, one would probably decide to do it slightly differently: to write it in Java and compile into native code directly.

1) every java developer with a relative minor lowlevel knowledge were able to develop a kernel module.

Writing a kernel module, which in 90% of cases is hardware related, requires more than a "minor" knowledge of hardware. People who do know Java but don't understand C profoundly are definitely not the right candidates for writing hardware drivers (or any other kernel modules).

Put in another perspective: would you trust your most important data (and I'm not even talking about being on life support controlled by such a kernel) to something running on a kernel written by people who don't understand C and assembly enough to write a reasonable driver in it?

2) (And it is the really intended goal): a JVM could solve the greatest problem of the kernel development, and it is the lack of the memory protection. A binary code segment compiled from java never caused any harm to data structures out of its scope, if there isn't another problem (f.e. jit compiler error or lowlevel hw problem), although the runtime safety checks of a such binary code caused a well measurable drawback in speed.

Memory protection with JIT? It requires pages to be both writeable and executable. That's a security nightmare even when it lacks direct memory access (in the sense of being able to use pointers).

If security (and thus code isolation among others) is your concern, microkernels are what you are after. You can even have one that is formally verified. Yet again, code can only be as good as the worst programmer whose code is still in - in the best case. Language as such isn't by far as important as the people who use it.

By the way, I strongly suggest reading this answer on system programming in various languages on SO.

3
  • "In the end if, writing kernel code in Java was the ultimate goal, one would probably decide to do it slightly differently: to write it in Java and compile into native code directly." No! Java's great not because of the language but because of the JVM. For example, the JVM does heroic optimizations which are impossible for statically-compiled OOP languages (like inlining virtual calls) and then lets you connect a debugger and then when you set a breakpoint it deoptimizes the relevant code to let you step through it. It's mindblowing and changes how one develops. Dec 14, 2020 at 17:25
  • "Another problem to solve would be interfacing any hardware. You would need a rather non-trivial piece of code that would allow the Java code to access e.g. network card, ... This would lead to a substantial piece of code being written in another language" No it wouldn't. You can map a range of memory using a ByteBuffer and do bit twiddling, which is 90% of a driver, and call C methods which is the other 10% (JEP 191 will improve this). But higher-level, Java lets you more easily create more sophisticated and more elegant logic so that drivers are smarter, faster, and have fewer bugs. Dec 14, 2020 at 17:34
  • @AleksandrDubinsky "it does heroic optimizations ... then it deoptimizes the code ..." - so you are saying the running code is being changed while it is run. I'm afraid we are coming from totally different backgrounds and with pretty much opposite expectations when it comes to system development. As for interfacing HW, yes FFI would help. 90%/10% - do you have a source? Higher language, less bugs - do you have a source? I'd really love to see some real world data.
    – peterph
    Dec 14, 2020 at 22:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .