"We present an experimental implementation of the Java Virtual Machine that runs inside the kernel of the Solaris operating system. The implementation was done by porting an existing small, portable JVM, Squawk, into the Solaris kernel. Our first application of this system is to allow device drivers to be written in Java. A simple device driver was ported from C to Java. Characteristics of the Java device driver and our device driver interface are described."

Vritualization....I think it's more interesting to run drivers in a real hardware-virtualized VM and run there the C driver (or java, or whatever) at full spedd without compromises. You get all the safety you want from embedding a java VM in the kernel, and more. Embedding a compiler in the kernel (the java vm is just a compiler + an interpreter after all) is just wrong IMNSHO

"Embedding a compiler in the kernel (the java vm is just a compiler + an interpreter after all) is just wrong IMNSHO"

I don't agree. If JVM is already there, there is nothing to prevent adding libraries and framework there, and that opens opportunities for more ideas. Don't forget, Dtrace is also(but not just) a compiler in kernel.

According to the paper, response time was down 17% and throughput was down 280-380% depending on whether a garbage collection was hit or not. However, they note that the JVM they used wasn't very optimized, and didn't even include a compiler so it was just running as an interpreter.

It's not of much use when the VM isn't freely available or redistributable.

Umm...of course it have value if the VM isn't freely available or redistributable.

It helps proof the technology. It helps work out the integration issues and expose the fundamental problems of things like VMs running within the kernel.

All of that needs some kind of test bed for folks to work on and investigate the problem space.

The advantages of such a technology has many pros: the potential for portable drivers is one, but more so, the ability to right more robust drivers more quickly is, to me, the predominant benefit of such an endeavor. It lets developers work out the "hard parts" in an ideally more safe environment than C, and less risk and turn around time.

Once they have a stable VM driver, they can then, perhaps, port it to C for performance if/when that becomes necessary.

For portable drivers, if the VM version of the driver is portable, but fully functional and not necessarily performant, it at least provides a solid framework to allow others to port the driver to C for their specific platform, since the VM driver is a working skeleton and example exposing the inner guts of the drivers implementation.

Finally, of course, it goes with out mention that whining about a freely distributable version of the VM is a completely dead horse as that train is running, and Sun is already on the path to an OSS Java and JVM. Now, it's simply a matter of time.

Of course it has value, but the situation you describe looks more like an academic research project to me, rather than a real solution to the lack of drivers for platforms other than Windows and to a lesser extent Linux x86. Sorry that this wasn't clear.

@PipoDeClown - read it. they do some performance tests. It is slower (not 2-3X slower though ). That said, they haven't optimized.

I wonder how this will increase the portability of drivers (if it can be done in solaris, other OSs can do it), not to mention other architectures. Since a lot of code would be very specific I imagine some parts would still be very unique. Unless of course they could create generic driver interface for certain kinds of drivers.

My guess is that it will have no effect on that. Portability of drivers has really little to do with their binary form and the processor it's targetted at, much more to do with the API of the underlying driver model.

Create quality device drivers is becoming increasingly complex. Microsoft is researching an entire OS written in C# (Singularity). Sun has been toying with the idea also. It's only a matter of time that the OS core will contain a managed enviornment.

for device drivers would be ideal. I agree with whartung . Since many OSs are open source and are woorked in spare time it would be ideal to have an (e.g.) Java Bluetooth driver and then ported it to C when time is available. This is interesting reading and would have solved a lot of problems. C is better but Java permits RAD. I do not want to argue on C vs Java since they are suitable for different needs, but there are people out there who need their HW working initially slow BlueTooth/FireWire/IrDa/USB and then faster if time permits it. But they want it to work. Of course Java does not rectify the problem of lack of Documentation, but it helps leverage the HW independent stacks like the above. Even SATA could be written in Java and then ported to C.

All this talk about 'porting' drivers from Java to C just makes me laugh. The only way this could be helpful is if the interfaces to the OS were the same. If they aren't, there's plenty of testing/debugging to do when the port happens, and just means you implement the driver twice...

Also, Java can't protect you from screwing over the DMA controller or some such, which is (in my experience) more often the kind of problem you run into while developing drivers then not freeing memory....

I know that plain Java doesn't have access to memory addresses of variables (at least the last time I used it), so I was interested to read how they came up with a scheme of providing functions for an Addr java class that allow you to manipulate and work with memory addresses without worrying about the garbage collection interfering.

On another note, I think this particular example should not be getting anyone's hopes up about Java in a kernel. They specificially chose a RAM disk because it is as they call "a pseudo-device driver that did not deal with a real I/O device." The point here is that this device driver is quite trivial compared to something that has to service hardware interrupts (from a "real" device) in a timely fashion. Doubling or tripling the time it takes to service these could result in some interesting (not so good) things happening.

"""The C programming language enables the creation of flexible and efficient software. C is traditionally used to write system software, including operating system kernels. However, because of the lack of type and memory safety and the burden of manual memory management, it is error-prone, unsafe, and the resulting software is often vulnerable to security attacks, such as those exploiting buffer overruns."""

Surely there is some middle-ground between C which doesn't even check array boundaries and encourages the reckless use of pointers... and putting a whole Java VM in kernel space! (Yeah, that sounds secure.)