“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.”
interesting but is it fast?
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.
Will this add to the name Slowlaris?
Not kernel-mode Java, but a VM-based method of implementing device drivers. Is that not the “holy grail” of device drivers: write once, support every platform/OS?
It’s not of much use when the VM isn’t freely available or redistributable.
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.
It was reported half a year ago that a group of people in Sun lab(in Brazil?) were working on running multi-task JVM. Not sure how things goes on now.
I am looking forward to JVM being one background service of Solaris, that would boost Java application start up speed, and help to make them integrate better with the OS and desktop environment.
Pretty cool read
@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.
I dunno. Just ponderings.
> I wonder how this will increase the portability 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.
Once upon a time there was UDI ( Uniform Driver Interface – http://projectudi.sourceforge.net/ ): that is what would give you drivers portability, not a JVM.
Is it possible to do something similar now with the FUSE implementation on Linux using Java/C bindings? Just curious…
yes, is cool!
and hope that other os will follow.
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.
Isn’t Inferno already there?
what’ s inferno? (well in italian is hell, but…)
http://ftp.bme.hu/OS/inferno/faq.html
http://www.vitanuova.com/inferno/
Edited 2006-10-20 16:26
thankyou!
i think JNode is doing it already.
IIRC, the driver in that paper doesn’t access any device, and the paper doesn’t mention how they propose to do MMIO from Java.
The teaseme VM integrated into the Linux kernel and is worth a look:
http://teaseme.sourceforge.net/
It seems development has stalled on it. It could be nice if there were a Java API for writing cross platform device drivers.
“””The teaseme VM integrated into the Linux kernel and is worth a look:”””
Dear Linus,
We’re sending you this patch to integrate a Java VM into the vanilla Linux kernel in hopes that you will merge it.
Kind regards,
The teaseme developers
Next By Thread ->
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….
Yes it is true, but there can be framework drivers that you can inherit from. Just another question. Why has project UDI failed? Any ideas?
IMHO UDI failed because all OSses are different. For example, the Win32 kernel APIs don’t fit very well into the BeOS kernel architecture, etc, etc.
Designing a single arch for drivers means that you have to get people to agree on a single ‘standard’ kernel API.
This is close to impossible, just take a look at the linux kernel mailing list archives and search for ‘stable kernel api’
(Please note that doing Linux kernel development is my current job, so I’m trying to bash Linux here
)
Edited 2006-10-21 14:34
darn, _not_ bashing Linux here I meant ofcourse
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.
From the paper:
“””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.)
Sheesh!
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!
Sure there is, it’s called C++.
Somehow I think a kernel with a Java VM would *not* be a microkernel
What we really need is a CISC processor with a dedicated JAVA instruction.
still aren’t as good as IE’s.