projects
/
nestedvm.git
/ commitdiff
commit
grep
author
committer
pickaxe
?
search:
re
summary
|
shortlog
|
log
|
commit
| commitdiff |
tree
raw
|
patch
|
inline
| side by side (parent:
a5ac4a3
)
remove pdftex-specific stuff from paper
author
adam
<adam@megacz.com>
Fri, 14 May 2004 08:12:07 +0000
(
01:12
-0700)
committer
adam
<adam@megacz.com>
Fri, 14 May 2004 08:12:07 +0000
(
01:12
-0700)
darcs-hash:
20040514081207
-5007d-
4849ad0df552aea1bd264e58ec1383c713ab9ebf
.gz
doc/ivme04.tex
patch
|
blob
|
history
diff --git
a/doc/ivme04.tex
b/doc/ivme04.tex
index
c9ea61d
..
13500be
100644
(file)
--- a/
doc/ivme04.tex
+++ b/
doc/ivme04.tex
@@
-5,11
+5,11
@@
\sloppy
\usepackage{palatino}
\usepackage{url}
\sloppy
\usepackage{palatino}
\usepackage{url}
-\usepackage{pdftricks}
-\begin{psinputs}
- \usepackage{pstricks}
- \usepackage{pst-node}
-\end{psinputs}
+%\usepackage{pdftricks}
+%\begin{psinputs}
+\usepackage{pstricks}
+\usepackage{pst-node}
+%\end{psinputs}
\usepackage{parskip}
\usepackage{tabularx}
\usepackage{alltt}
\usepackage{parskip}
\usepackage{tabularx}
\usepackage{alltt}
@@
-122,7
+122,7
@@
The four program representations of interest in this context, along
with their specific types in the C-to-JVM instantiation of the
problem are shown in the following diagram:
with their specific types in the C-to-JVM instantiation of the
problem are shown in the following diagram:
-\begin{pdfpic}
+%\begin{pdfpic}
\newlength{\MyLength}
\settowidth{\MyLength}{machine code}
\newcommand{\MyBox}[1]{\makebox[\MyLength][c]{#1}}
\newlength{\MyLength}
\settowidth{\MyLength}{machine code}
\newcommand{\MyBox}[1]{\makebox[\MyLength][c]{#1}}
@@
-138,15
+138,15
@@
problem are shown in the following diagram:
& \\[0pt]
\psset{nodesep=5pt,arrows=->}
\end{psmatrix}
& \\[0pt]
\psset{nodesep=5pt,arrows=->}
\end{psmatrix}
-\end{pdfpic}
+%\end{pdfpic}
To illustrate the context of this diagram, the following arcs show the
translations performed by a few familiar tools:
To illustrate the context of this diagram, the following arcs show the
translations performed by a few familiar tools:
-\begin{pdfpic}
-\newlength{\MyLength}
-\settowidth{\MyLength}{xmachine codex}
-\newcommand{\MyBox}[1]{\makebox[\MyLength]{#1}}
+%\begin{pdfpic}
+%\newlength{\MyLength}
+%\settowidth{\MyLength}{xmachine codex}
+%\newcommand{\MyBox}[1]{\makebox[\MyLength]{#1}}
\psmatrix[colsep=2,rowsep=0,nrot=:D]
& \\[0pt]
[name=s0]\MyBox{unsafe source} & [name=s1]\MyBox{safe source} \\[0pt]
\psmatrix[colsep=2,rowsep=0,nrot=:D]
& \\[0pt]
[name=s0]\MyBox{unsafe source} & [name=s1]\MyBox{safe source} \\[0pt]
@@
-163,7
+163,7
@@
translations performed by a few familiar tools:
\ncline{s1}{b1}\aput{:U}{\tt javac}
\ncline{b1}{b0}\aput{:D}{\tt gcj}\bput{:D}{JITs}
\endpsmatrix
\ncline{s1}{b1}\aput{:U}{\tt javac}
\ncline{b1}{b0}\aput{:D}{\tt gcj}\bput{:D}{JITs}
\endpsmatrix
-\end{pdfpic}
+%\end{pdfpic}
Existing techniques for translating unsafe code into VM bytecode
generally fall into two categories, which we expand upon in the
Existing techniques for translating unsafe code into VM bytecode
generally fall into two categories, which we expand upon in the
@@
-175,10
+175,10
@@
source-to-binary translation.
The most common technique employed is partial translation from unsafe
source code to safe source code:
The most common technique employed is partial translation from unsafe
source code to safe source code:
-\begin{pdfpic}
-\newlength{\MyLength}
-\settowidth{\MyLength}{xmachine codex}
-\newcommand{\MyBox}[1]{\makebox[\MyLength]{#1}}
+%\begin{pdfpic}
+%\newlength{\MyLength}
+%\settowidth{\MyLength}{xmachine codex}
+%\newcommand{\MyBox}[1]{\makebox[\MyLength]{#1}}
\psmatrix[colsep=2,rowsep=0,nrot=:U]
& \\[0pt]
& \\[0pt]
\psmatrix[colsep=2,rowsep=0,nrot=:U]
& \\[0pt]
& \\[0pt]
@@
-194,7
+194,7
@@
source code to safe source code:
\ncline{s0}{s1}\aput{:U}{source-to}\bput{:U}{source}
\ncline{s1}{b1}\aput{:U}{\tt javac}
\endpsmatrix
\ncline{s0}{s1}\aput{:U}{source-to}\bput{:U}{source}
\ncline{s1}{b1}\aput{:U}{\tt javac}
\endpsmatrix
-\end{pdfpic}
+%\end{pdfpic}
A number of existing systems employ this technique; they can
be divided into two categories: those which perform a partial
A number of existing systems employ this technique; they can
be divided into two categories: those which perform a partial
@@
-255,10
+255,10
@@
process.
Source-to-binary translation involves a compiler for the unsafe
language which has been modified to emit safe bytecode.
Source-to-binary translation involves a compiler for the unsafe
language which has been modified to emit safe bytecode.
-\begin{pdfpic}
-\newlength{\MyLength}
-\settowidth{\MyLength}{xmachine codex}
-\newcommand{\MyBox}[1]{\makebox[\MyLength]{#1}}
+%\begin{pdfpic}
+%\newlength{\MyLength}
+%\settowidth{\MyLength}{xmachine codex}
+%\newcommand{\MyBox}[1]{\makebox[\MyLength]{#1}}
\psmatrix[colsep=2,rowsep=0,nrot=:U]
& \\[0pt]
[name=s0]\MyBox{unsafe source} & [name=s1]\MyBox{safe source} \\[0pt]
\psmatrix[colsep=2,rowsep=0,nrot=:U]
& \\[0pt]
[name=s0]\MyBox{unsafe source} & [name=s1]\MyBox{safe source} \\[0pt]
@@
-272,7
+272,7
@@
language which has been modified to emit safe bytecode.
\psset{nodesep=5pt,arrows=->}
\ncline{s0}{b1}\bput{:U}{source-to-binary}
\endpsmatrix
\psset{nodesep=5pt,arrows=->}
\ncline{s0}{b1}\bput{:U}{source-to-binary}
\endpsmatrix
-\end{pdfpic}
+%\end{pdfpic}
An experimental ``JVM backend'' for the {\tt gcc} compiler, known as
{\tt egcs-jvm} \cite{egcsjvm}, attempts this approach. Since {\tt
An experimental ``JVM backend'' for the {\tt gcc} compiler, known as
{\tt egcs-jvm} \cite{egcsjvm}, attempts this approach. Since {\tt
@@
-382,7
+382,7
@@
carry a performance penalty on physical MIPS implementations.
Our choice of a paged representation for memory carries only a small
performance disadvantage:
Our choice of a paged representation for memory carries only a small
performance disadvantage:
-\epsfig{file=charts/chart5,width=3in}
+\epsfig{file=charts/chart5,height=2.7in,angle=-90}
Additionally, this representation lets us to take advantage of the
fact that on most JVM's, checking for a {\tt NullPointerException}
Additionally, this representation lets us to take advantage of the
fact that on most JVM's, checking for a {\tt NullPointerException}
@@
-437,10
+437,10
@@
translation. In this mode, NestedVM translates MIPS binaries into
Java source code, which is then fed to a Java compiler in order to
produce bytecode files:
Java source code, which is then fed to a Java compiler in order to
produce bytecode files:
-\begin{pdfpic}
-\newlength{\MyLength}
-\settowidth{\MyLength}{xmachine codex}
-\newcommand{\MyBox}[1]{\makebox[\MyLength]{#1}}
+%\begin{pdfpic}
+%\newlength{\MyLength}
+%\settowidth{\MyLength}{xmachine codex}
+%\newcommand{\MyBox}[1]{\makebox[\MyLength]{#1}}
\psmatrix[colsep=2,rowsep=0,nrot=:U]
& \\[0pt]
& \\[0pt]
\psmatrix[colsep=2,rowsep=0,nrot=:U]
& \\[0pt]
& \\[0pt]
@@
-456,7
+456,7
@@
produce bytecode files:
\ncline{s1}{b1}\aput{:U}{\tt javac}
\ncline{b0}{s1}\naput{\tt NestedVM}
\endpsmatrix
\ncline{s1}{b1}\aput{:U}{\tt javac}
\ncline{b0}{s1}\naput{\tt NestedVM}
\endpsmatrix
-\end{pdfpic}
+%\end{pdfpic}
\begin{figure*}[t]
\begin{minipage}[c]{7in}%
\begin{figure*}[t]
\begin{minipage}[c]{7in}%
@@
-539,10
+539,10
@@
Translating unsafe code for use within a JVM proceeds as follows:
After implementing the binary-to-source compiler, a binary-to-binary
translation mode was added.
After implementing the binary-to-source compiler, a binary-to-binary
translation mode was added.
-\begin{pdfpic}
-\newlength{\MyLength}
-\settowidth{\MyLength}{xmachine codex}
-\newcommand{\MyBox}[1]{\makebox[\MyLength]{#1}}
+%\begin{pdfpic}
+%\newlength{\MyLength}
+%\settowidth{\MyLength}{xmachine codex}
+%\newcommand{\MyBox}[1]{\makebox[\MyLength]{#1}}
\psmatrix[colsep=2,rowsep=0,nrot=:U]
& \\[0pt]
[name=s0]\MyBox{unsafe source} & [name=s1]\MyBox{safe source} \\[0pt]
\psmatrix[colsep=2,rowsep=0,nrot=:U]
& \\[0pt]
[name=s0]\MyBox{unsafe source} & [name=s1]\MyBox{safe source} \\[0pt]
@@
-557,7
+557,7
@@
translation mode was added.
\ncline{s0}{b0}\bput{:U}{\tt gcc}
\ncline{b0}{b1}\naput{\tt NestedVM}
\endpsmatrix
\ncline{s0}{b0}\bput{:U}{\tt gcc}
\ncline{b0}{b1}\naput{\tt NestedVM}
\endpsmatrix
-\end{pdfpic}
+%\end{pdfpic}
This mode has several advantages:
This mode has several advantages:
@@
-707,7
+707,7
@@
local variables for registers did not offer much of a performance
advantage, presumably since the JVM's JIT is intelligent enough to
register-allocate temporaries for fields.
advantage, presumably since the JVM's JIT is intelligent enough to
register-allocate temporaries for fields.
-\epsfig{file=charts/chart4,width=3in}
+\epsfig{file=charts/chart4,height=2.7in,angle=-90}
Unfortunately, Java imposes a 64kb limit on the size of the bytecode
for a single method. This presents a problem for NestedVM, and
Unfortunately, Java imposes a 64kb limit on the size of the bytecode
for a single method. This presents a problem for NestedVM, and
@@
-752,7
+752,7
@@
methods invoked from the trampoline. Trial and error led to the
conclusion that HotSpot \cite{hotspot} -- the most widely deployed JVM
-- performs best when 128 MIPS instructions are mapped to each method.
conclusion that HotSpot \cite{hotspot} -- the most widely deployed JVM
-- performs best when 128 MIPS instructions are mapped to each method.
-\epsfig{file=charts/chart1,width=3in}
+\epsfig{file=charts/chart1,height=2.7in,angle=-90}
This phenomenon is due to two factors:
This phenomenon is due to two factors:
@@
-832,7
+832,7
@@
file) eliminates this problem entirely.
Compiling directly to bytecode offers a substantial performance gain:
Compiling directly to bytecode offers a substantial performance gain:
-\epsfig{file=charts/chart3,width=3in}
+\epsfig{file=charts/chart3,height=2.7in,angle=-90}
Most of this improvement comes from the handling of branch
instructions and from taking advantage of the JVM stack to eliminate
Most of this improvement comes from the handling of branch
instructions and from taking advantage of the JVM stack to eliminate
@@
-918,7
+918,7
@@
case} arm shrinks by one instruction.
The net result is quite reasonably sized {\tt .class} files:
The net result is quite reasonably sized {\tt .class} files:
-\epsfig{file=charts/chart9,width=3in}
+\epsfig{file=charts/chart9,height=2.7in,angle=-90}
\subsection{Compiler Flags}
\subsection{Compiler Flags}
@@
-981,7
+981,7
@@
source-to-MIPS compiler:
The following chart quantifies the performance gain conferred by each
of the major optimizations outlined in this section:
The following chart quantifies the performance gain conferred by each
of the major optimizations outlined in this section:
-\epsfig{file=charts/chart10,width=3in}
+\epsfig{file=charts/chart10,height=2.7in,angle=-90}
@@
-1000,11
+1000,11
@@
and {\tt verdan32.exe}. The {\tt libfreetype} test consisted of
rendering ASCII characters 32-127 of {\tt Comic.TTF} at sizes from 8
to 48 incrementing by 4 for a total of 950 glyphs.
rendering ASCII characters 32-127 of {\tt Comic.TTF} at sizes from 8
to 48 incrementing by 4 for a total of 950 glyphs.
-\epsfig{file=charts/chart8,width=3in}
+\epsfig{file=charts/chart8,height=2.7in,angle=-90}
-\epsfig{file=charts/chart7,width=3in}
+\epsfig{file=charts/chart7,height=2.7in,angle=-90}
-\epsfig{file=charts/chart6,width=3in}
+\epsfig{file=charts/chart6,height=2.7in,angle=-90}
\section{Sample Applications}
\section{Sample Applications}
@@
-1069,7
+1069,7
@@
for checking the ``cpu time'' of a process. Unfortunately we had to
substitute wall-clock time on an otherwise-quiescent machine as an
approximation.
substitute wall-clock time on an otherwise-quiescent machine as an
approximation.
-\epsfig{file=charts/chart11,width=3in}
+\epsfig{file=charts/chart11,height=2.7in,angle=-90}