%% -*- mode: LaTeX -*-
%%
%% Copyright (c) 2002 University of Utah and the Flux Group.
%% All rights reserved.
%% This file is part of the JanosVM documentation.
%% 
%% Permission to use, copy, modify, distribute, and sell this
%% documentation for any purpose is hereby granted without fee,
%% provided that the above copyright notice(s) appear in all copies.
%%

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\chapter{Overview of \JanosVMplain{}}
\label{cha:Overview of JanosVM}

This chapter presents a high level overview of the concepts and reasoning
behind much of the \JanosVM{}.  You should be able to skip directly to the
installation and tutorial if you're in a hurry, however, some things will be
hard to fully understand without this background.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\section{Motivation}
\label{sec:Motivation}

As more and more computers become networked together their collective power to
do both good and harm grows at an incredible rate.  Presently, however, the
ability for users to take advantage of all the available computing power
requires some amount of trust and a somewhat homogenous computing environment.
There exist individual solutions for each problem, operating systems with
proper security and resource controls can prevent buggy or malicious code from
running amok and high level language runtimes can function consistently in
heterogeneous environments.  However, simply composing these systems can result
in a suboptimal whole that lacks expressivity, scaling ability, performance and
countless other unknowns.  Of course, these problems can already be seen in
everyday environments as language runtimes soak up \CPU{} and memory to execute
redundant bootstrapping code for each executed program.  Therefore, we have
proposed and implemented, with great results, a number of systems which
replicate and enhance many of the operating system's services in the Java
language runtime.  Now, with these results in hand we have taken the
opportunity to further refine and explore the design space with \JanosVM{}.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\section{History}
\label{sec:Histroy}

This section will concentrate on \JanosVM{}'s pedigree, a great deal of
wonderful work and experience went into the development of the system.  The
three main systems we'll discuss are:

\begin{itemize}
  \item KaffeOS - The last in a long line of Java \OS{} designs using a
	monolithic kernel.

  \item Alta - A hierarchically based Java \OS{} similar in design to the
	\Fluke{} micro-kernel.

  \item Migrating Threads in Mach 3.0 - An extension to Mach that performed
	local \IPC{} by quickly switching the process context of a thread.
\end{itemize}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\subsection{KaffeOS}
\label{subsec:KaffeOS}

\JanosVM{} is a direct descendant of \KaffeOS{}~\cite{Back+:osdi00}, a fully operational system
that can run most Java code "out of the box" with only minor modifications.
The design of \KaffeOS{} takes advantage of language based protections and,
like current operating systems, uses a monolithic kernel to control access to
globally shared services.  The language based protections allowed the system to
take advantage of direct sharing between user processes, shared heaps, and the
kernel without compromising the security of the system.  The monolithic kernel
and the important state change of entering/leaving the kernel served to protect
any globally shared data from the unexpected termination of processes and their
threads.  In addition, \KaffeOS{} could exert control and accurate accounting
over \CPU{} and memory resources used by processes in the system.  For the
\CPU{}, this was accomplished through a stride scheduler written for the user
level threading library.  In the case of memory, each process was given its own
garbage collector to track usage and to separate the amount of \CPU{} used
during collection and finalization.

Unfortunately,
%% cough
\KaffeOS{} isn't
%% cough
publicly available
%% wink
at this writing.
%% wink...


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\subsection{Alta}
\label{subsec:Alta}

Alta~\cite{Tullmann:ms99} is an earlier Java-based operating system.  Unlike \KaffeOS{} and
\JanosVM{} the garbage collector was not separated into per-process components,
instead Alta concentrated on class and data sharing between {\em spaces}
(Alta's term for the process abstraction).

Alta is based on the Fluke nested process model, a model for hierarchically
organizing processes in a system, whereby processes are wholly "contained" (all
resources and interfaces are granted to) by their parent process.  In Alta,
Java processes could share data through a client-server style interprocess
communication (\IPC{}) mechanism.  The most important aspect of Alta, with
respect to \JanosVM{}, was the type and object sharing.  The type sharing in
Alta was defined at run-time as types were referenced in the child.  The
dynamic nature created performance and correctness problems that \JanosVM{} was
designed to avoid.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\subsection{Migrating Threads in Mach 3.0}
\label{subsec:Migrating Threads in Mach 3.0}

Extending Mach 3.0 to use migrating threads~\cite{migr-usenix} in place of the standard \IPC{}
mechanism resulted in better performance, functionality, and simplified code.
While not the first work on migrating threads, it is the one implemented here
% XXX say `Utah' somewhere?
at Utah, so it has had the most direct impact.  Thread
migration involves switching the outer context of a thread to another process
in the system, an operation very similar to a thread trapping into a kernel.
The benefit of this approach primarily has to do with the reduction of
overhead between the client and server threads.  For instance, the system only
needs to change to the foreign address space, there is no full context switch to
the server thread.  Besides the performance improvements, migration simplifies
programming by removing the rendezvous and message passing between client and
server threads.  Finally, the merging of the disparate threads allows for more
accurate accounting and control of the operations performed by client threads.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\subsection{Kaffe}
\label{subsec:Kaffe}

% XXX cite www.kaffe.org?
Ultimately, the core of the \JanosVM{} is the \Kaffe{} Virtual Machine~\cite{Kaffe:URL},
originally developed by Transvirtual Technologies.  So, we thank them and the
many volunteer contributors for their work.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\subsection{Lessons Learned} % ??
\label{subsec:Lessons Learned}

These three systems served as the basis for much of the \JanosVM{}'s design.
\KaffeOS{}'s code base and overall design became the starting point, while
thread migration and Alta's flexible typing provided some interesting
variation.  However, there were several changes in the final implementation of
the \JanosVM{}, usually in favor of making the system more resilient in the
face of faults.  First, the \KaffeOS{} garbage collector was changed to drop a
processes' memory instead of merging it into the kernel's heap.  This removed
the possibility of process memory allocated by native code leaking into the
kernel, an occasional source of grief while working on \KaffeOS{}.  Next,
thread migration was used to replace the transition between user processes and
the kernel, thus allowing threads to switch to peer or server processes.
Because the system is a single address space, there is no significant
additional overhead in this change and it enables the use of a microkernel-like
design.  Of course, one could ignore service partitioning in favor of a single
process that does everything, but this goes against the desires for fault
tolerance.  Finally, a modified version of the Alta type system was added to
enable simple class sharing as well as type renaming.  This addition allowed
\JanosVM{} to continue to use a modified version of the \javaid{java.lang}
package without precluding the possibility of a true \JDK{} compatible version.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\section{Language Protection Basics}
\label{sec:Language Protection Basics}

Narrowing the scope of supported user languages and having direct control over
their execution affords a number of benefits over hardware based protections.
First, type safety guarantees the integrity and security of the system, even
though data and code for multiple processes exist in the same address space.
Next, member access control tags like public and private allow for fine grained
control over what untrusted code can see and execute.  Finally, it becomes
easier to manipulate the final code executed by the \CPU{}, allowing the
introduction of write barriers or other runtime checks.

A major tool leveraged by the \JanosVM{} is the type safety inherent in the Java
language.  This protection makes it possible to place trusted data and code
in the same address space as user code without sacrificing the security of the
system.  In \JanosVM{} this is taken to an extreme by completely ignoring the
interface to untrusted user code in favor of providing flexibility for one or
more middleware layers.  For example, creating a new process in the \JanosVM{}
does not automatically execute the \javaid{main} method of some class, instead
the middleware library is expected to migrate into the new process and start a
thread that will call the desired methods.  This means more work for the
middleware developer, but greatly increases the amount of flexibility they have
in performing their tasks.

Cross process sharing of object references is another major benefit of language
protected operating systems.  While it is not a panacea, it does allow for more
direct sharing between processes than a hardware protected \OS{}.  For example,
many classes and their read only data can be directly shared with no major
repercussions.  In addition, system managed proxies can allow limited sharing
of objects between mutually suspicious processes.

%% XXX I feel like more should be added here...

% XXX define concepts like team, Importable, Exportable...


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

%% End of file.

