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).