gcjik

Fri Sep 20 11:41:00 GMT 2002

______________________________________________________________________________
Short Version
Hey, has anybody toyed around with gcj-compiled binaries running
without access to the MMU (ie can't catch sigsegv)?
I can do without the garbage collector; my main concern is
NullPointerException's. Is there some way to get gcc to emit a "if
null throw NullPointerException" before each object reference?
Performance isn't too important here.
Also, other than having to tweak the GC, is there anything greviously
wrong with CNI code constructing a jvbytearray whose data pointer
points at arbitrary places in memory? For example, if I already have
an array of bytes, and I want to share it with Java code without
copying it.
Are there any other issues I should be aware of?
______________________________________________________________________________
Long Version
So why am I asking about this?
Well, I decided to take graduate operating systems this semester at
Berkeley for kicks, and we're supposed to do some sort of interesting
project that qualifies as "new research".
I thought it would be interesting to write a patch for the Linux
kernel that allows a setuid-root utility ('gcjik') to take a .jar from
an untrusted user, pass it to a (trusted) copy of gcj, and load the
resulting binary image directly into the running kernel. Since
gcj-compiled code is 'safe', there's (theoretically) no danger in
running the code in ring zero, even if you don't trust the user who
wrote the code.
A compiled-class cache (keyed off of the class name and md5 sum of the
source .class file) can be used to eliminate redundant recompilations.
This would give Java what is (IMHO) one of .NET's few advantages --
mandatory, static, upfront compilation.
Various CNI glue APIs could be written to give the Java code safe
access to stuff like the scheduler, VM, network layer, etc.
Interestingly, this API could be kernel-agnostic, allowing the same
kernel jars to work on FreeBSD, Linux, or Solaris.
Implications:
 - Lets you write/prototype new OS features in Java rather than C;
 much easier, less risky.
 - Essentially all the stuff the Mach microkernel was supposed to let
 us do [*]
 - User-written filesystems (without performance-killing round
 trips to a user-mode daemon)
 - User-written network stacks
 - User-written, *interrupt-context* packet handlers; ie fast,
 user-written flexible routers.
 - User-written VM pagers (database people have been drooling
 over this for a long time now)
 - Eventually, far in the future, I can see this as being the
 primary mechanism for running Java code -- instead of a JVM, you
 won't think twice about loading your code directly into the
 kernel. The Linux jar-executable-type handler could use gcjik.
 - Take this idea far enough, and you can eventually obsolete
 the entire notion of an MMU and erase the distinction between
 the OS and the applications running on it (okay, this is
 getting a big grandiose, I know...).
 - This is quite similar to NetApp's approach (their filers run
 BSD with in-kernel samba, nfs, appletalk, httpd, etc) applied
 to general-purpose computers rather than fixed-purpose file
 serving devices.
Caveats:
 - I'm not going to try to get the GC or threads to work for the
 first revision. I'm also going to ignore the multitude of
 denial-of-service attacks for now; these can be worked around
 with timers and memory quotas in a future release.
 - a
------------------------------------------------------------------------------
[*] Mach died because modern CPUs TLB caches are too small to support
 multi-server operating systems without thrashing. In-kernel Java
 code gets around this by using language safety instead of the MMU
 for protection, so switching from the "real" kernel to the
 "custom" kernel stuff doesn't require updates to the TLB.