Linked by Thom Holwerda on Fri 20th Oct 2006 14:02 UTC, submitted by Ian Rogers
Sun Solaris, OpenSolaris "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."
Order by: Score:
virtualization
by PipoDeClown on Fri 20th Oct 2006 14:33 UTC
PipoDeClown
Member since:
2005-07-19

interesting but is it fast?

Reply Score: 2

RE: virtualization
by diegocg on Fri 20th Oct 2006 14:47 UTC in reply to "virtualization"
diegocg Member since:
2005-07-08

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

Reply Score: 1

RE[2]: virtualization
by rayx on Fri 20th Oct 2006 14:57 UTC in reply to "RE: virtualization"
rayx Member since:
2006-03-24

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

Reply Score: 1

RE: virtualization
by smitty on Fri 20th Oct 2006 15:01 UTC in reply to "virtualization"
smitty Member since:
2005-10-13

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.

Reply Score: 2

v Slow?
by intosi on Fri 20th Oct 2006 14:34 UTC
It's about time.
by SpasmaticSeacow on Fri 20th Oct 2006 14:43 UTC
SpasmaticSeacow
Member since:
2006-02-17

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?

Reply Score: 5

RE: It's about time.
by LB06 on Fri 20th Oct 2006 14:44 UTC in reply to "It's about time."
LB06 Member since:
2005-07-06

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

Reply Score: 1

RE[2]: It's about time.
by whartung on Fri 20th Oct 2006 16:55 UTC in reply to "RE: It's about time."
whartung Member since:
2005-07-06

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.

Reply Score: 4

RE[3]: It's about time.
by LB06 on Fri 20th Oct 2006 19:00 UTC in reply to "RE[2]: It's about time."
LB06 Member since:
2005-07-06

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.

Reply Score: 1

That's cool!
by rayx on Fri 20th Oct 2006 14:45 UTC
rayx
Member since:
2006-03-24

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.

Reply Score: 1

pretty cool
by Yamin on Fri 20th Oct 2006 14:54 UTC
Yamin
Member since:
2006-01-10

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.

Reply Score: 2

RE: pretty cool
by falemagn on Sat 21st Oct 2006 04:37 UTC in reply to "pretty cool"
falemagn Member since:
2005-07-06

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

Reply Score: 2

Very cool!
by EmmEff on Fri 20th Oct 2006 15:18 UTC
EmmEff
Member since:
2005-09-16

Is it possible to do something similar now with the FUSE implementation on Linux using Java/C bindings? Just curious...

Reply Score: 1

RE: Very cool!
by gelosilente on Fri 20th Oct 2006 15:29 UTC in reply to "Very cool!"
gelosilente Member since:
2006-08-13

yes, is cool!
and hope that other os will follow.

Reply Score: 1

Natural Evolution
by atehrani on Fri 20th Oct 2006 15:48 UTC
atehrani
Member since:
2006-10-20

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.

Reply Score: 1

RE: Natural Evolution
by orestes on Fri 20th Oct 2006 16:01 UTC in reply to "Natural Evolution"
orestes Member since:
2005-07-06

Isn't Inferno already there?

Reply Score: 1

RE[2]: Natural Evolution
by gelosilente on Fri 20th Oct 2006 16:16 UTC in reply to "RE: Natural Evolution"
gelosilente Member since:
2006-08-13

what' s inferno? (well in italian is hell, but...)

Reply Score: 1

RE[3]: Natural Evolution
by orestes on Fri 20th Oct 2006 16:25 UTC in reply to "RE[2]: Natural Evolution"
orestes Member since:
2005-07-06
RE[4]: Natural Evolution
by gelosilente on Sat 21st Oct 2006 07:01 UTC in reply to "RE[3]: Natural Evolution"
gelosilente Member since:
2006-08-13

thankyou!

Reply Score: 1

RE: Natural Evolution
by ahmetaa on Fri 20th Oct 2006 18:52 UTC in reply to "Natural Evolution"
ahmetaa Member since:
2005-07-06

i think JNode is doing it already.

Reply Score: 1

Device drivers without devices
by Wes Felter on Fri 20th Oct 2006 16:14 UTC
Wes Felter
Member since:
2005-11-15

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.

Reply Score: 1

Teaseme
by captain5050 on Fri 20th Oct 2006 19:01 UTC
captain5050
Member since:
2006-04-08

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.

Reply Score: 1

RE: Teaseme
by sbergman27 on Fri 20th Oct 2006 21:01 UTC in reply to "Teaseme"
sbergman27 Member since:
2005-07-24

"""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 ->

Reply Score: 3

Yes but RAD..
by fithisux on Sat 21st Oct 2006 10:51 UTC
fithisux
Member since:
2006-01-22

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.

Reply Score: 1

RE: Yes but RAD..
by Ithamar on Sat 21st Oct 2006 13:35 UTC in reply to "Yes but RAD.."
Ithamar Member since:
2006-03-20

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

Reply Score: 1

RE[2]: Yes but RAD..
by fithisux on Sat 21st Oct 2006 14:11 UTC in reply to "RE: Yes but RAD.."
fithisux Member since:
2006-01-22

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?

Reply Score: 1

RE[3]: Yes but RAD..
by Ithamar on Sat 21st Oct 2006 14:33 UTC in reply to "RE[2]: Yes but RAD.."
Ithamar Member since:
2006-03-20

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

Reply Score: 1

RE[4]: Yes but RAD..
by Ithamar on Sat 21st Oct 2006 14:35 UTC in reply to "RE[3]: Yes but RAD.."
Ithamar Member since:
2006-03-20

darn, _not_ bashing Linux here I meant ofcourse ;)

Reply Score: 1

Java & Memory Access
by joecool on Sat 21st Oct 2006 18:56 UTC
joecool
Member since:
2006-02-19

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.

Reply Score: 1

sbergman27
Member since:
2005-07-24

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!

Reply Score: 1

falemagn Member since:
2005-07-06

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

Reply Score: 1

microkernel
by mjones on Sat 21st Oct 2006 20:31 UTC
mjones
Member since:
2006-06-14

Somehow I think a kernel with a Java VM would *not* be a microkernel :-)

Reply Score: 1

RE: microkernel
by rcsteiner on Mon 23rd Oct 2006 15:20 UTC in reply to "microkernel"
rcsteiner Member since:
2005-07-12

What we really need is a CISC processor with a dedicated JAVA instruction. :-)

Reply Score: 1

bookmarks
by Eric Martin on Mon 23rd Oct 2006 18:51 UTC
Eric Martin
Member since:
2005-11-11

still aren't as good as IE's.

Reply Score: 1