corrections

darcs-hash:20040319023858-24bed-a746dc4bf25831579c4bb12f0f9c43c09dd68f87.gz

diff --git a/doc/nestedvm.ivme04.tex b/doc/nestedvm.ivme04.tex
index 19ff75f..aa823a7 100644 (file)
--- a/doc/nestedvm.ivme04.tex
+++ b/doc/nestedvm.ivme04.tex
@@ -189,7 +189,7 @@ running C/C++ code within a Java VM is shown in Figure~\ref{lattice}.
 
 A number of commercial products and research projects attempt to
 translate C++ code to Java code, preserving the mapping of C++ classes
 
 A number of commercial products and research projects attempt to
 translate C++ code to Java code, preserving the mapping of C++ classes

-to Java classes.  Unfortunately this is problematic since there is no
+to Java classes.  Unfortunately, this is problematic since there is no

 way to do pointer arithmetic except within arrays, and even in that
 case, arithmetic cannot be done in terms of fractional objects.
 
 way to do pointer arithmetic except within arrays, and even in that
 case, arithmetic cannot be done in terms of fractional objects.
 

@@ -383,11 +383,11 @@ public void trampoline() {
 \caption{\label{code1} Trampoline transformation necessitated by Java's 64kb method size limit}
 \end{figure*}
 
 \caption{\label{code1} Trampoline transformation necessitated by Java's 64kb method size limit}
 \end{figure*}
 

-Unfortunately Java imposes a 64kb limit on the size of the bytecode
+Unfortunately, Java imposes a 64kb limit on the size of the bytecode

 for a single method.  This presents a problem for NestedVM, and
 necessitates a {\it trampoline transformation}, as shown in
 Figure~\ref{code1}.  With this trampoline in place somewhat large
 for a single method.  This presents a problem for NestedVM, and
 necessitates a {\it trampoline transformation}, as shown in
 Figure~\ref{code1}.  With this trampoline in place somewhat large

-binaries can be handled without much difficulty -- fortunately there
+binaries can be handled without much difficulty -- fortunately, there

 is no corresponding limit on the size of a classfile as a whole.
 
 Another interesting problem that was discovered while creating the
 is no corresponding limit on the size of a classfile as a whole.
 
 Another interesting problem that was discovered while creating the

@@ -487,10 +487,10 @@ identified. The sources for possible jump targets come from 3 places.
 Eliminating unnecessary case statements provided a 10-25\% speed
 increase.
 
 Eliminating unnecessary case statements provided a 10-25\% speed
 increase.
 

-Despite all the above optimizations and workaround an impossible to
+Despite all the above optimizations and workarounds an impossible to

 workaround hard classfile limit was eventually hit, the constant
 pool. The constant pool in classfiles is limited to 65536
 workaround hard classfile limit was eventually hit, the constant
 pool. The constant pool in classfiles is limited to 65536

-entries. Every Integer with a magnitude greater than 32767 requires an
+entries. Every integer with a magnitude greater than 32767 requires an

 entry in the constant pool. Every time the compiler emits a
 jump or branch instruction the PC field is set to the branch target. This
 means nearly every branch instruction requires an entry in the
 entry in the constant pool. Every time the compiler emits a
 jump or branch instruction the PC field is set to the branch target. This
 means nearly every branch instruction requires an entry in the

@@ -555,7 +555,7 @@ if(condition) { pc = TARGET; continue; }
 This requires a branch in the JVM regardless of whether the MIPS
 branch is actually taken. If condition is false the JVM has to jump
 over the code to set the PC and go back to the switch block. If
 This requires a branch in the JVM regardless of whether the MIPS
 branch is actually taken. If condition is false the JVM has to jump
 over the code to set the PC and go back to the switch block. If

-condition is true the JVM as to jump to the switch block. By
+condition is true the JVM has to jump to the switch block. By

 generating bytecode directly we can make the target of the JVM branch
 statement the actual bytecode of the final destination. In the case
 where the branch isn't taken the JVM doesn't need to branch at all.
 generating bytecode directly we can make the target of the JVM branch
 statement the actual bytecode of the final destination. In the case
 where the branch isn't taken the JVM doesn't need to branch at all.

@@ -615,7 +615,7 @@ registers are not visible to the branch bytecode. This allows delay
 slots to be used with no performance penalty or size penalty.
 
 One final advantage that generating bytecode directly allows is
 slots to be used with no performance penalty or size penalty.
 
 One final advantage that generating bytecode directly allows is

-smaller more compact bytecode. All the optimization above lead to
+smaller more compact bytecode. All the optimizations above lead to

 smaller bytecode as a side effect. There are also a few other areas
 where the generated bytecode can be optimized for size with more
 knowledge of the program as a whole.
 smaller bytecode as a side effect. There are also a few other areas
 where the generated bytecode can be optimized for size with more
 knowledge of the program as a whole.

@@ -643,15 +643,15 @@ NestedVM has two primary ways of executing code, the interpreter, and the binary
 
 \subsection{The Runtime Class}
 
 
 \subsection{The Runtime Class}
 

-The Runtime class does the work that the operating system usually does. Conceptually the Runtime class can be though of as the operating system and itÕs subclasses (translated binaries and the interpreter) the CPU. The Runtime fulfills 5 primary goals:
+The Runtime class does the work that the operating system usually does. Conceptually the Runtime class can be thought of as the operating system and itÕs subclasses (translated binaries and the interpreter) the CPU. The Runtime fulfills 5 primary goals:

 
 \begin{itemize}
 
 
 \begin{itemize}
 

-\item Provides a consistent external interface - Because only Runtime exposes a public interface the method of actually executing the code (currently only translated binaries and the interpreter) can be changed without any code changes.
+\item Provides a consistent external interface - The method of actually executing the code (currently only translated binaries and the interpreter) can be changed without any code changes to the caller because only Runtime exposes a public interface.

 
 \item Provide an easy to use interface - The interpreter and the output from the binary translators only know how to execute code. The Runtime class provides an easy to use interface to the code. It contains methods to pass arguments to the main() function, read and write from memory, and call individual functions in the binary.
 
 
 \item Provide an easy to use interface - The interpreter and the output from the binary translators only know how to execute code. The Runtime class provides an easy to use interface to the code. It contains methods to pass arguments to the main() function, read and write from memory, and call individual functions in the binary.
 

-\item Manage the processÕs memory - The Runtime class contains large int[] arrays that represent the processÕs entire memory space.  Subclasses read and write to these arrays as required by the instructions they are executing.  Subclasses can expend their memory space using the sbrk syscall.
+\item Manage the processÕs memory - The Runtime class contains large int[] arrays that represent the process`s entire memory space.  Subclasses read and write to these arrays as required by the instructions they are executing.  Subclasses can expend their memory space using the sbrk syscall.

 
 \item Provide access to the file system and streams - Subclasses access the file system through standard UNIX syscalls (read, write,  open, etc). The Runtime manages the file descriptor table that maps UNIX file descriptors to Java RandomAccessFiles, InputStreams, OutputStreams, and sockets.
 
 
 \item Provide access to the file system and streams - Subclasses access the file system through standard UNIX syscalls (read, write,  open, etc). The Runtime manages the file descriptor table that maps UNIX file descriptors to Java RandomAccessFiles, InputStreams, OutputStreams, and sockets.
 

@@ -755,7 +755,7 @@ Adam, we should cite "Using the GNU Compiler Collection" somewhere in here.
 \begin{itemize}
 
 \item {\tt -falign-functions}
 \begin{itemize}
 
 \item {\tt -falign-functions}

-Normally a function's location in memory has no effect on its execution speed. However, in the NestedVM binary translator the .text segment is split up on a power of two boundary. If a function is unlucky enough to start near the end of one of these boundaries a performance critical part of the function could end up spanning two methods. There is a significant amount of overhead in switching between two methods so this must be avoided at all costs. By telling GCC to align all functions to the boundary that the .text segment is split on the chances of a critical part of a function spanning two methods is significantly reduced.
+Normally a function's location in memory has no effect on its execution speed. However, in the NestedVM binary translator, the .text segment is split up on power of two boundaries. If a function is unlucky enough to start near the end of one of these boundaries a performance critical part of the function could end up spanning two methods. There is a significant amount of overhead in switching between two methods so this must be avoided at all costs. By telling GCC to align all functions to the boundary that the .text segment is split on the chances of a critical part of a function spanning two methods is significantly reduced.

 
 \item {\tt -fno-rename-registers}
 Some processors can better schedule code when registers aren't reused for two different purposes. By default GCC will try to use as many registers as possibly when it can. This excess use of registers just confuses JIT's trying to compile the output from the binary translator. All the JIT compilers we tested do much better with a few frequently used registers.
 
 \item {\tt -fno-rename-registers}
 Some processors can better schedule code when registers aren't reused for two different purposes. By default GCC will try to use as many registers as possibly when it can. This excess use of registers just confuses JIT's trying to compile the output from the binary translator. All the JIT compilers we tested do much better with a few frequently used registers.