Updates based on new knowledge.

1 files changed, 34 insertions, 26 deletions

diff --git a/doc/vmintegration.texinfo b/doc/vmintegration.texinfo
index 5efb8876e..7eaeb96bb 100644
--- a/doc/vmintegration.texinfo
+++ b/doc/vmintegration.texinfo
@@ -71,33 +71,37 @@ level of integration with the Virtual Machine, the underlying machinery
 that actually runs Java.
 
 There are several VMs out there, including
-@uref{http://www.japhar.org,Japhar} and
-@uref{http://www.kaffe.org,Kaffe}.  Current integration efforts are
-focused solely on Japhar, in order to get the basic interface down, and
-all information contained in this document is gleaned from these
-efforts.
+@uref{http://www.japhar.org,Japhar},
+@uref{http://www.kaffe.org,Kaffe}, and
+@uref{http://www.mozilla.org/projects/ef,Electrical Fire}.  Current
+integration efforts are focused mainly on Japhar with an eye towards
+getting Electrical Fire to work.  All information contained in this
+document is gleaned from these efforts.
 
 
 @node Initialization, Classpath Hooks, Introduction, Top
 @comment node-name, next, previous, up
 @chapter Initialization
 
-The order of initialization of classes is not so crucial to the Virtual
-Machine, but is absolutely critical to Classpath itself.  This section
-shows the order in which classes should be loaded and initialized in
-order for things to work properly.
-
-XXX Not ready yet.
-
+The order of initialization, as far as I can tell, doesn't matter just
+yet.  However, when we move to 1.2 support, it probably will matter, so
+we'll have a note in here at that time.
 
 @node Classpath Hooks, VM Hooks, Initialization, Top
 @comment node-name, next, previous, up
 @chapter Classpath Hooks
 
 Several core classes must be implemented by the VM for Classpath to
-work.  These classes are java.lang.Runtime, java.lang.Thread,
-java.lang.Class, java.lang.reflect.Constructor,
-java.lang.reflect.Method, and java.lang.reflect.Field.
+work.  These classes are:
+
+@itemize @bullet
+@item java.lang.Runtime
+@item java.lang.Thread
+@item java.lang.Class
+@item java.lang.reflect.Constructor
+@item java.lang.reflect.Method
+@item java.lang.reflect.Field
+@end itemize
 
 You also need to implement some helper classes in java.lang that classes
 from Classpath call out to to get certain VM-specific dirty work done:
@@ -127,7 +131,7 @@ Call this method from Thread when a Thread is stopped or destroyed.
 
 @node VM Hooks, JNI Hooks, Classpath Hooks, Top
 @comment node-name, next, previous, up
-@chapter Introduction
+@chapter VM Hooks
 
 VMs need to do some dirty work; there are some things in the VM that
 unfortunately are dependent on the internal structure of various
@@ -148,7 +152,8 @@ When you are creating an array class, you should set the ClassLoader of
 the array class to the ClassLoader of its component type.  Whenever you
 add a class to a ClassLoader, you need to notify the ClassLoader and
 add the new Class to its internal cache of classes.  To do this, call
-ClassLoader.addVMCreatedClass(Class).
+ClassLoader.addVMCreatedClass(Class).  @em{Note: this is written in
+anticipation of 1.2 support and does not apply just yet.}
 
 @item primordial class loader
 When the primordial class loader loads a class, it needs to tell
@@ -161,10 +166,14 @@ simply call this method @emph{after} the initial class loading has been
 done.  No harm will come, as long as you follow the guidelines in the
 @pxref{Initialization} section.
 
+@em{Note: this is written in anticipation of 1.2 support and does not
+apply just yet.}
+
 @item throwing exceptions
 You do not need to fill in the stack trace or anything when throwing an
 exception; this is all handled automatically with Classpath when the
-constructor is called.
+constructor is called.  Of course, you are really the ones filling it in
+because you implement StackTrace and StackFrame.
 
 @item top-level exception handler
 Exceptions take care of themselves in Classpath; all you need to do in
@@ -178,7 +187,7 @@ even do some sort of lazy stacktrace information addition to the
 Throwable, only copying stacktrace data as it is lost (as functions are
 exited) to preserve memory and cycles.  The usual case is the one where
 an exception is caught.  The top-level exception handler is, well, an
-exception.
+exception among exceptions.
 
 @item Security and traces
 There will eventually be a feature in the 1.2 security that keeps the
@@ -196,15 +205,14 @@ do the check.  I am not sure, however, whether the savings are
 substantial enough to outweigh the integer check and set after every
 method call.  I will investigate.
 
-@item java.lang.Thread
-You should not need to mess with the internal structure of this class,
-even though threading is native to the VM, because there is typically
-a native thread structure that you are using.  The Thread object will,
-of course, have to be linked to that native thread structure, and how
-you do that is up to you.
+@item Threading
+I figured I'd put this here because a VM guy might be wondering about it.
+We implement ThreadGroup, but that class is almost entirely
+VM-independent.  The root ThreadGroup, a static field called
+ThreadGroup.root, should be initialized by Classpath, but if you wish to
+reinitialize it yourself, there should be no harm.
 
 @end itemize
 
 
 @bye
-