gcjik

[Adam Megacz <gcj at lists dot megacz dot com>]

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