Panchaleswar Nayak's Weblog

I was reading published paper by Hiroshi Yamauchi & Mario Wolczko at Sun Microsystems Laboratories.
"Writing Solaris Device Drivers in Java"
It is quite interesting to know there is an effort to port the JVM embedded in the Solaris kernel. There system is based on the Squawk virtual machine.The Squawk virtual machine core is mostly written in Java. It has an interpreter, and a just-in-time compiler. The lower-level parts and the main loop of the interpreter are written in C, while the more complex instructions (such as those dealing with monitors) are implemented in Java.
They have created and tested a RamDisk Device Driver written in Java.
They performed the following simple performance measurements to compare the Java version of the driver to the C version.
The measurements were performed on a Sun E420R system with four 450MHz UltraSPARC II CPUs and 1GB of RAM, using Solaris 10 (Build 76).
1. Raw system call overhead We measured the time to call the close system call on the RAM disk device. Because the close function of the RAM disk driver is empty, the measurement yields the total overhead from the system call down to the device driver routine and back. We repeated the measurement ten times and computed the average time. The Java version took 4.48 microseconds whereas the C version took 3.84 microseconds, an overhead of 16.7%. The virtual machine was given 512 KB of heap.
2. Throughput We measured the time to copy a 1MB file within the RAM disk. This measurement should indicate the performance of the block I/O of the driver. We repeated the measurement ten times and computed the average time. The Java version took 178 microseconds and the C version took 63 microseconds. When a GC occurred during a copy, the Java version took 230 microseconds. The Java version took approximately 2.8 times and 3.8 times longer than the C version without and with a GC, respectively. The virtual machine was given 512 KB of heap. We believe the overhead in the Java version is mainly due to bytecode interpretation. The results are encouraging because the Squawk virtual machine we used was an early unoptimized version,with a just-in-time compiler in development.
But what I see is if Java based device drivers are developed then the same driver can be used for both SPARC and X86 platform without modification provided the JVM is ported to both SPARC and x86.And may be if the JVM is ported to Linux then same driver can be used in linux too.
If you want to get the PDF file for the technical details then you can get it from
http://research.sun.com/techrep/2006/smli_tr-2006-156.pdf

The porpose of writing these docs are to educate the community about the real time aspect of Solaris Operating System.Step by Step I will try to write how we can use solaris for running realtime applications. Basic Rules of Real-time Applications. Real-time response is guaranteed when certain conditions are met. In This section I will discuss these conditions and some of the more significant design errors. Most of the potential problems described here can degrade the response time of the system. One of the potential problems can freeze a workstation. Other, more subtle,mistakes are priority inversion and system overload. A Solaris real-time process has the following characteristics: Runs in the RT scheduling class, as described in “The Real-Time Scheduler”. Locks down all the memory in its process address space. The Real-Time Scheduler Interface Calls That Control Scheduling Using priocntl Control over scheduling of active classes is done with priocntl(2). Class attributes are inherited through fork(2) and exec(2), along with scheduling parameters and permissions required for priority control. This inheritance happens with both the RT and the TS classes. priocntl(2) is the interface for specifying a real-time process, a set of processes, or a class to which the system call applies. priocntlset(2) also provides the more general interface for specifying an entire set of processes to which the system call applies. The command arguments of priocntl(2) can be one of: PC_GETCID,PC_GETCLINFO, PC_GETPARMS, or PC_SETPARMS. The real or effective ID of the calling process must match the real or effective ID of the affected processes, or must have superuser privilege. PC_GETCID This command takes the name field of a structure that contains a recognizable class name. The class ID and an array of class attribute data are returned. PC_GETCLINFO This command takes the ID field of a structure that contains a recognizable class identifier. The class name and an array of class attribute data are returned. PC_GETPARMS This command returns the scheduling class identifier or the class specific scheduling parameters of one of the specified processes.Even though idtype and id might specify a big set,PC_GETPARMS returns the parameter of only one process. The class selects the process. PC_SETPARMS This command sets the scheduling class or the class-specific scheduling parameters of the specified process or processes.

Sun has long appreciated the importance of real-time applications. The Solaris Operating Environment was architected with a solid real-time foundation from its inception in 1987. In particular, Sun realized the power of combining both real-time and time-share capabilities in a volume, commercial off-the-shelf (COTS) operating system. This approach gives real-time systems access to extensive application availability, a flexible development environment for native real-time applications, and standards-based application portability.

Beyond these advantages, the Solaris Operating Environment allows real-time deployment systems to scale to meet increasing application demands. As computational load increases, additional processors can be added to the system for either time-share or real-time tasks — providing not only time-share, but real-time enterprise scalability. Systems can even be dynamically reconfigured to provide proportionally more dedicated, real-time computation resources on an as-needed basis.

No matter how attractive these advantages are, real-time applications have stringent timing requirements that must be taken into consideration in order for an operating system to be considered for deployment.
Tomorrow I will discuss the Real-time Programming and Administration in the Solaris™ Operating Environment.