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).
Best Answer
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":
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.