function call. This function creates a unique representation of this
class, identified by its name, in the JVM's internal \textit{class
-hashtable}. The newly created \texttt{classinfo} structure (Figure
-\ref{classinfostructure}) is initialized with correct values, like
-\texttt{loaded = false;}, \texttt{linked = false;} and
+hashtable}. The newly created \texttt{classinfo} structure (see
+figure~\ref{classinfostructure}) is initialized with correct values,
+like \texttt{loaded = false;}, \texttt{linked = false;} and
\texttt{initialized = false;}. This guarantees a definite state of a
new class.
voidptr *cpinfos; /* pointer to constant pool info structures */
classinfo *super; /* super class pointer */
- ...
+ classinfo *sub; /* sub class pointer */
+ classinfo *nextsub; /* pointer to next class in sub class list */
+
s4 interfacescount; /* number of interfaces */
classinfo **interfaces; /* pointer to interfaces */
This wrapper function is required to ensure some requirements:
\begin{itemize}
- \item enter a monitor on the \texttt{classinfo} structure, so that
- only one thread can load the same class at the same time
+ \item enter a monitor on the \texttt{classinfo} structure to make
+ sure that only one thread can load the same class or interface at the
+ same time
+
+ \item check if the class or interface is \texttt{loaded}, if it is
+ \texttt{true}, leave the monitor and return immediately
\item measure the loading time if requested
structure from the internal class hashtable if we got an error or
exception during loading
- \item free any allocated memory and leave the monitor
+ \item free any allocated memory
+
+ \item leave the monitor
\end{itemize}
The \texttt{class\_load} function is implemented to be
Loading \texttt{signed} values is done via the
\texttt{suck\_s[1,2,4,8]} macros which cast the loaded bytes to
\texttt{signed} values. All these functions take a
-\texttt{classbuffer} (Figure \ref{classbufferstructure}) structure
-pointer as argument.
+\texttt{classbuffer} (see figure~\ref{classbufferstructure})
+structure pointer as argument.
\begin{figure}[h]
\begin{verbatim}
\end{verbatim}
from the \texttt{constant\_pool} table in the binary representation of
-the class of interface. The constant pool needs to be parsed in two
-passes. In the first pass the information loaded is saved in temporary
-structures, which are further processed in the second pass, when the
-complete constant pool has been traversed. Only when the whole
-constant pool entries have been loaded, any constant pool entry can be
-completely resolved, but this resolving can only be done in a specific
-order:
+the class of interface. The \texttt{classinfo} structure has two
+pointers to arrays which contain the class' constant pool infos,
+namely: \texttt{cptags} and \texttt{cpinfos}. \texttt{cptags} contains
+the type of the constant pool entry. \texttt{cpinfos} contains a
+pointer to the constant pool entry itself.
+
+The constant pool needs to be parsed in two passes. In the first pass
+the information loaded is saved in temporary structures, which are
+further processed in the second pass, when the complete constant pool
+has been traversed. Only when all constant pool entries have been
+processed, every constant pool entry can be completely resolved, but
+this resolving can only be done in a specific order:
\begin{enumerate}
\item \texttt{CONSTANT\_Class}
\item \texttt{CONSTANT\_NameAndType}
- \item \texttt{CONSTANT\_Fieldref}, \texttt{CONSTANT\_Methodref} and
- \texttt{CONSTANT\_InterfaceMethodref} --- these are combined into one
- structure
+ \item \texttt{CONSTANT\_Fieldref} \\ \texttt{CONSTANT\_Methodref} \\
+ \texttt{CONSTANT\_InterfaceMethodref} --- these entries are combined
+ into one structure
\end{enumerate}
-\begingroup
-\tolerance 10000
-The remaining constant pool types \texttt{CONSTANT\_Integer},
-\texttt{CONSTANT\_Float}, \texttt{CONSTANT\_Long},
-\texttt{CONSTANT\_Double} and \texttt{CONSTANT\_Utf8} can be
-completely resolved in the first pass and need no further processing.
-
-\endgroup
-
-The temporary structures, shown in Figure
-\ref{constantpoolstructures}, are used to \textit{forward} the data
-from the first pass into the second.
+The temporary structures which are used to \textit{forward} the data
+from the first pass into the second, are shown in
+figure~\ref{constantpoolstructures}.
\begin{figure}[h]
\begin{verbatim}
\label{constantpoolstructures}
\end{figure}
-The \texttt{classinfo} structure has two pointers to arrays which
-contain the class' constant pool infos, namely: \texttt{cptags} and
-\texttt{cpinfos}. \texttt{cptags} contains the type of the constant
-pool entry. \texttt{cpinfos} contains a pointer to the constant pool
-entry itself. In the second pass the references are resolved and the
-runtime structures are created. In further detail this includes for
+The following list describes how the constant pool entries, which need
+two passes, are processed in the first pass.
+
+\begin{itemize}
+
+ \item \texttt{CONSTANT\_Class}
+
+ \begin{itemize}
+ \item create a new \texttt{forward\_class} structure
+
+ \item add the \texttt{forward\_class} structure to the
+ \texttt{forward\_classes} list
+
+ \item store the current constant pool index into the
+ \texttt{thisindex} field
+
+ \item read the index of the class' name via \texttt{suck\_u2} and
+ store it into the \texttt{name\_index} field
+
+ \item increase the constant pool index by one
+ \end{itemize}
+
+ \item \texttt{CONSTANT\_String}
+
+ \begin{itemize}
+ \item create a new \texttt{forward\_string} structure
+
+ \item add the \texttt{forward\_string} structure to the \texttt{forward\_strings} list
+
+ \item store the current constant pool index into the \texttt{thisindex} field
+
+ \item read the index of the UTF8 string via \texttt{suck\_u2} and store it into the \texttt{name\_index} field
+
+ \item increase the constant pool index by one
+ \end{itemize}
+
+ \item \texttt{CONSTANT\_NameAndType}
+
+ \begin{itemize}
+ \item create a new \texttt{forward\_nameandtype} structure
+
+ \item add the \texttt{forward\_nameandtype} structure to the
+ \texttt{forward\_nameandtypes} list
+
+ \item store the current constant pool index into the
+ \texttt{thisindex} field
+
+ \item read the index of the UTF8 string containing the name via
+ \texttt{suck\_u2} and store it into the \texttt{name\_index} field
+
+ \item read the index of the UTF8 string containing the field or
+ method descriptor via \texttt{suck\_u2} and store it into the
+ \texttt{sig\_index} field
+
+ \item increase the constant pool index by one
+ \end{itemize}
+
+ \item \texttt{CONSTANT\_Fieldref} \\ \texttt{CONSTANT\_Methodref} \\
+ \texttt{CONSTANT\_InterfaceMethodref}
+
+ \begin{itemize}
+ \item create a new \texttt{forward\_fieldmethint} structure
+
+ \item add the \texttt{forward\_fieldmethint} structure to the
+ \texttt{forward\_fieldmethints} list
+
+ \item store the current constant pool index into the
+ \texttt{thisindex} field
+
+ \item store the current constant pool type into the \texttt{tag}
+ field
+
+ \item read the constant pool index of the \texttt{CONSTANT\_Class}
+ entry that contains the declaration of the field or method via
+ \texttt{suck\_u2} and store it into the \texttt{class\_index} field
+
+ \item read the constant pool index of the
+ \texttt{CONSTANT\_NameAndType} entry that contains the name and
+ descriptor of the field or method and store it into the
+ \texttt{nameandtype\_index} field
+
+ \item increase the constant pool index by one
+
+ \end{itemize}
+
+\end{itemize}
+
+The remaining constant pool types can be completely resolved in the
+first pass and need no further processing. These types, including the
+actions taken in the first pass, are as follows:
+
+\begin{itemize}
+
+ \item \texttt{CONSTANT\_Integer}
+
+ \begin{itemize}
+
+ \item create a new \texttt{constant\_integer} structure (see
+ figure~\ref{constantintegerstructure})
+
+ \item read a 4 byte \texttt{signed integer} value via
+ \texttt{suck\_s4} from the binary representation
+
+ \item store the value into the \texttt{value} field of the
+ \texttt{constant\_integer} structure
+
+ \item store the type \texttt{CONSTANT\_Integer} into \texttt{cptags}
+ and the pointer to the \texttt{constant\_integer} structure into
+ \texttt{cpinfos} at the appropriate index
+
+ \item increase the constant pool index by one
+
+ \end{itemize}
+
+\begin{figure}[h]
+\begin{verbatim}
+ typedef struct { /* Integer */
+ s4 value;
+ } constant_integer;
+\end{verbatim}
+\caption{\texttt{constant\_integer} structure}
+\label{constantintegerstructure}
+\end{figure}
+
+ \item \texttt{CONSTANT\_Float}
+
+ \begin{itemize}
+
+ \item create a new \texttt{constant\_float} structure (see
+ figure~\ref{constantfloatstructure})
+
+ \item read a 4 byte \texttt{float} value via \texttt{suck\_float}
+ from the binary representation
+
+ \item store the value into the \texttt{value} field of the
+ \texttt{constant\_float} structure
+
+ \item store the type \texttt{CONSTANT\_Float} into \texttt{cptags}
+ and the pointer to the \texttt{constant\_float} structure into
+ \texttt{cpinfos} at the appropriate index
+
+ \item increase the constant pool index by one
+
+ \end{itemize}
+
+\begin{figure}[h]
+\begin{verbatim}
+ typedef struct { /* Float */
+ float value;
+ } constant_float;
+\end{verbatim}
+\caption{\texttt{constant\_float} structure}
+\label{constantfloatstructure}
+\end{figure}
+
+ \item \texttt{CONSTANT\_Long}
+
+ \begin{itemize}
+
+ \item create a new \texttt{constant\_long} structure (see
+ figure~\ref{constantlongstructure})
+
+ \item read a 8 byte \texttt{signed long} value via \texttt{suck\_s8}
+ from the binary representation
+
+ \item store the value into the \texttt{value} field of the
+ \texttt{constant\_long} structure
+
+ \item store the type \texttt{CONSTANT\_Long} into \texttt{cptags}
+ and the pointer to the \texttt{constant\_long} structure into
+ \texttt{cpinfos} at the appropriate index
+
+ \item increase the constant pool index by two
+
+ \end{itemize}
+
+\begin{figure}[h]
+\begin{verbatim}
+ typedef struct { /* Long */
+ s8 value;
+ } constant_long;
+\end{verbatim}
+\caption{\texttt{constant\_long} structure}
+\label{constantlongstructure}
+\end{figure}
+
+ \item \texttt{CONSTANT\_Double}
+
+ \begin{itemize}
+
+ \item create a new \texttt{constant\_double} structure (see
+ figure~\ref{constantdoublestructure})
+
+ \item read a 8 byte \texttt{double} value via \texttt{suck\_double}
+ from the binary representation
+
+ \item store the value into the \texttt{value} field of the
+ \texttt{constant\_double} structure
+
+ \item store the type \texttt{CONSTANT\_Double} into \texttt{cptags}
+ and the pointer to the \texttt{constant\_double} structure into
+ \texttt{cpinfos} at the appropriate index
+
+ \item increase the constant pool index by two
+
+ \end{itemize}
+
+\begin{figure}[h]
+\begin{verbatim}
+ typedef struct { /* Double */
+ double value;
+ } constant_double;
+\end{verbatim}
+\caption{\texttt{constant\_double} structure}
+\label{constantdoublestructure}
+\end{figure}
+
+ \item \texttt{CONSTANT\_Utf8}
+
+ \begin{itemize}
+
+ \item read the length of the UTF8 string via \texttt{suck\_u2}
+
+ \item store the type \texttt{CONSTANT\_Utf8} into \texttt{cptags} at
+ the appropriate index
+
+ \item create a new UTF8 string in the runtime environment of the
+ Java Virtual Machine via \texttt{utf\_new\_intern}
+
+ \item store the pointer of the newly created UTF8 string into
+ \texttt{cpinfos} at the appropriate index
+
+ \item skip \texttt{length} bytes in the binary representation of the
+ class or interface via \texttt{skip\_nbytes}
+
+ \item increase the constant pool index by one
+
+ \end{itemize}
+
+\end{itemize}
+
+In the second pass, the references are resolved and the runtime
+structures are created. In further detail this includes for
\begin{itemize}
- \item \texttt{CONSTANT\_Class}: get the UTF8 name string of the
- class, store type \texttt{CONSTANT\_Class} in \texttt{cptags}, create
- a class in the class hashtable with the UTF8 name and store the
- pointer to the new class in \texttt{cpinfos}
-
- \item \texttt{CONSTANT\_String}: get the UTF8 string of the
- referenced string, store type \texttt{CONSTANT\_String} in
- \texttt{cptags} and store the UTF8 string pointer into
- \texttt{cpinfos}
-
- \begingroup
- \tolerance 10000
- \item \texttt{CONSTANT\_NameAndType}: create a
- \texttt{constant\_nameandtype} (Figure \ref{constantnameandtype})
- structure, get the UTF8 name and description string of the field or
- method and store them into the \texttt{constant\_nameandtype}
- structure, store type \texttt{CONSTANT\_NameAndType} into
- \texttt{cptags} and store a pointer to the
- \texttt{constant\_nameandtype} structure into \texttt{cpinfos}
-
- \endgroup
+
+ \item \texttt{CONSTANT\_Class}
+
+ \begin{itemize}
+
+ \item resolve the UTF8 name string from the class' constant pool
+
+ \item store the type \texttt{CONSTANT\_Class} in \texttt{cptags} at
+ the appropriate index
+
+ \item create a class in the class hashtable with the UTF8 name
+
+ \item store the pointer to the new class in \texttt{cpinfos} at the
+ appropriate index
+
+ \end{itemize}
+
+ \item \texttt{CONSTANT\_String}
+
+ \begin{itemize}
+
+ \item resolve the UTF8 string of the referenced string from the
+ class' constant pool
+
+ \item store type \texttt{CONSTANT\_String} in \texttt{cptags} and
+ store the UTF8 string pointer into \texttt{cpinfos} at the
+ appropriate index
+
+ \end{itemize}
+
+ \item \texttt{CONSTANT\_NameAndType}
+
+ \begin{itemize}
+
+ \item create a new \texttt{constant\_nameandtype} structure (see
+ figure~\ref{constantnameandtype})
+
+ \item resolve the UTF8 name and description string of the field or
+ method and store them into the \texttt{constant\_nameandtype}
+ structure
+
+ \item store type \texttt{CONSTANT\_NameAndType} into
+ \texttt{cptags} and store a pointer to the
+ \texttt{constant\_nameandtype} structure into \texttt{cpinfos}
+
+ \end{itemize}
\begin{figure}[h]
\begin{verbatim}
\label{constantnameandtype}
\end{figure}
- \begingroup
- \tolerance 10000
- \item \texttt{CONSTANT\_Fieldref}, \texttt{CONSTANT\_Methodref} and
- \texttt{CONSTANT\_InterfaceMethodref}: create a
- \texttt{constant\_FMIref} (Figure \ref{constantFMIref}) structure,
- get the referenced \texttt{constant\_nameandtype} structure which
- contains the name and descriptor resolved in a previous step and
- store the name and descriptor into the \texttt{constant\_FMIref}
- structure, get the pointer of the referenced class, which was created
- in a previous step, and store the pointer of the class into the
- \texttt{constant\_FMIref} structure, store the type of the current
- constant pool entry in \texttt{cptags} and store a pointer to
- \texttt{constant\_FMIref} in \texttt{cpinfos}
-
- \endgroup
+ \item \texttt{CONSTANT\_Fieldref} \\
+ \texttt{CONSTANT\_Methodref} \\
+ \texttt{CONSTANT\_InterfaceMethodref}
+
+ \begin{itemize}
+
+ \item create a new \texttt{constant\_FMIref} structure (see
+ figure~\ref{constantFMIref})
+
+ \item resolve the referenced \texttt{constant\_nameandtype}
+ structure which contains the name and descriptor resolved in a
+ previous step and store the name and descriptor into the
+ \texttt{constant\_FMIref} structure
+
+ \item resolve the pointer of the referenced class which was created
+ in a previous step and store the pointer of the class into the
+ \texttt{constant\_FMIref} structure
+
+ \item store the type of the current constant pool entry in
+ \texttt{cptags} and store the pointer to \texttt{constant\_FMIref}
+ in \texttt{cpinfos} at the appropriate index
+
+ \end{itemize}
\begin{figure}[h]
\begin{verbatim}
\end{verbatim}
is called. The \texttt{fieldinfo *} argument is a pointer to a
-\texttt{fieldinfo} structure (Figure \ref{fieldinfostructure})
+\texttt{fieldinfo} structure (see figure~\ref{fieldinfostructure})
allocated by the class loader. The fields' \texttt{name} and
\texttt{descriptor} are resolved from the class constant pool via
\texttt{class\_getconstant}. If the verifier option is turned on, the
\subsection{Method loading}
+\label{sectionmethodloading}
As for the fields, the number of the class or interface methods is read from
the binary representation as \texttt{u2} value. For each method the function
processes the \texttt{LineNumberTable} attribute. A
\texttt{LineNumberTable} entry consist of the \texttt{start\_pc} and
the \texttt{line\_number}, which are stored in a \texttt{lineinfo}
-structure (Figure \ref{lineinfostructure}).
+structure (see figure~\ref{lineinfostructure}).
\begin{figure}[h]
\begin{verbatim}
function call to resolve the classes or UTF8 strings. After resolving
is done, all values are stored in the \texttt{innerclassinfo}
-structure (Figure \ref{innerclassinfostructure}).
+structure (see figure~\ref{innerclassinfostructure}).
\begin{figure}[h]
\begin{verbatim}
returned, there was an exception.
-\section{Dynamic class loader}
+%\section{Dynamic class loader}
\section{Eager - lazy class loading}
\subsection{Lazy class loading}
\label{sectionlazyclassloading}
-With \textit{eager class loading}, usually it takes much more time for
-a Java Virtual Machine to start a program as with \textit{lazy class
+Usually it takes much more time for a Java Virtual Machine to start a
+program with \textit{eager class loading} as with \textit{lazy class
loading}. With \textit{eager class loading}, a typical
\texttt{HelloWorld} program needs 513 class loads with the current GNU
classpath CACAO is using. When using \textit{lazy class loading},
some incompatibilities with other Java Virtual Machines like Sun's
JVM, IBM's JVM or Kaffe.
-Imagine a code snippet like this
+Given a code snippet like this
\begin{verbatim}
void sub(boolean b) {
classinfo *class_link(classinfo *c);
\end{verbatim}
-This function, as for class loading, is just a wrapper function for
-the main linking function
+This function, as for class loading, is just a wrapper function to the
+main linking function
\begin{verbatim}
static classinfo *class_link_intern(classinfo *c);
\texttt{static}. The purposes of the wrapper function are
\begin{itemize}
- \item enter a monitor on the \texttt{classinfo} structure, so that is
- guaranteed that only one thread can link the same class at the same
- time
+ \item enter a monitor on the \texttt{classinfo} structure, so that
+ only one thread can link the same class or interface at the same time
+
+ \item check if the class or interface is \texttt{linked}, if it is
+ \texttt{true}, leave the monitor and return immediately
\item measure linking time if requested
\texttt{class\_new} and then loaded and linked if not already
done. If none is the case, the passed array is a \textit{primitive
type array}. No matter of which type the array is, an
-\texttt{arraydescriptor} structure (Figure
-\ref{arraydescriptorstructure}) is allocated and filled with the
-appropriate values of the given array type.
+\texttt{arraydescriptor} structure (see
+figure~\ref{arraydescriptorstructure}) is allocated and filled with
+the appropriate values of the given array type.
\begin{figure}[h]
\begin{verbatim}
\label{arraydescriptorstructure}
\end{figure}
-After the \texttt{class\_link\_array} function call, the temporary
-class \texttt{index} is calculated. For interfaces---classes with
+After the \texttt{class\_link\_array} function call, the class
+\texttt{index} is calculated. For interfaces---classes with
\texttt{ACC\_INTERFACE} flag bit set---the class' \texttt{index} is
the global \texttt{interfaceindex} plus one. Any other classes get the
\texttt{index} of the superclass plus one.
is called. This function computes the highest interface \texttt{index}
of the passed interface and returns the value. This is done by
recursively calling \texttt{class\_highestinterface} with each
-interface from the passed interface. The highest \texttt{index} value
-found is the \textit{interface table length} of the currently linking
-class or interface.
+interface from the \texttt{interfaces} array of the passed interface
+as argument. The highest \texttt{index} value found is the
+\textit{interface table length} of the currently linking class or
+interface.
Now that the linker has completely computed the size of the
\textit{virtual function table}, the memory can be allocated, casted
-to an \texttt{vftbl} structure (Figure \ref{vftblstructure}) and
+to an \texttt{vftbl} structure (see figure~\ref{vftblstructure}) and
filled with the previously calculated values.
\begin{figure}
processed field. The type-size is then added to get the real
\texttt{instancesize}.
-The next step of the CACAO linker is to initialize the \textit{virtual
-function table} fields \texttt{interfacevftbllength} and
+The next step of the CACAO linker is to initialize two \textit{virtual
+function table} fields, namely \texttt{interfacevftbllength} and
\texttt{interfacetable}. For \texttt{interfacevftbllength} an
\texttt{s4} array of \texttt{interfacetablelength} elements is
allocated. Each \texttt{interfacevftbllength} element is initialized
v->interfacetable[-i] = MNEW(methodptr, ic->methodscount);
\end{verbatim}
-For each method of the interface passed, the methods of the target
-class or interface passed and all superclass methods are checked if
-they can overwrite the interface method via
-\texttt{method\_canoverwrite}. If the function returns \texttt{true},
-the corresponding function is resolved from the
+For each method of the passed interface, the methods of the passed
+target class or interface and all superclass methods, up to
+\texttt{java.lang.Object}, are checked if they can overwrite the
+interface method via \texttt{method\_canoverwrite}. If the function
+returns \texttt{true}, the corresponding function is resolved from the
\texttt{table} field of the \textit{virtual function table} and stored
it the particular position of the \texttt{interfacetable}:
find a function which name and descriptor matches
\texttt{finalize()V}. If an appropriate function was found and the
function is non-\texttt{static}, it is assigned to the
-\texttt{finalizer} field of the \texttt{classinfo} structure.
+\texttt{finalizer} field of the \texttt{classinfo} structure. CACAO
+does not assign the \texttt{finalize()V} function to
+\texttt{java.lang.Object}, because this function is inherited to all
+subclasses which do not explicitly implement a \texttt{finalize()V}
+method. This would mean, for each instantiated object, which is marked
+for collection in the Java Virtual Machine, an empty function would be
+called from the garbage collector when a garbage collection takes
+place.
+
+The final task of the linker is to compute the \texttt{baseval} and
+\texttt{diffval} values from the subclasses of the currently linked
+class or interface. These values are used for \textit{runtime type
+checking} (described in more detail in
+section~\ref{sectionruntimetypechecking}). The calculation is done via
+the
+
+\begin{verbatim}
+ void loader_compute_subclasses(classinfo *c);
+\end{verbatim}
+
+function call. This function sets the \texttt{nextsub} and
+\texttt{sub} fields of the \texttt{classinfo} structure, resets the
+global \texttt{classvalue} variable to zero and calls the
+
+\begin{verbatim}
+ static void loader_compute_class_values(classinfo *c);
+\end{verbatim}
+
+function with \texttt{java.lang.Object} as parameter. First of the
+all, the \texttt{baseval} is set of the currently passed class or
+interface. The \texttt{baseval} is the global \texttt{classvalue}
+variable plus one:
+
+\begin{verbatim}
+ c->vftbl->baseval = ++classvalue;
+\end{verbatim}
+
+Then all subclasses of the currently passed class or interface are
+processed. For each subclass found,
+\texttt{loader\_compute\_class\_values} is recursively called. After
+all subclasses have been processed, the \texttt{diffval} of the
+currently passed class or interface is calculated. It is the
+difference of the current global \texttt{classvalue} variable value
+and the previously \texttt{baseval} set:
+
+\begin{verbatim}
+ c->vftbl->diffval = classvalue - c->vftbl->baseval;
+\end{verbatim}
+
+After the \texttt{baseval} and \texttt{diffval} values are newly
+calculated for all classes and interfaces in the Java Virtual Machine,
+the internal linker function \texttt{class\_link\_intern} returns the
+currently linking \texttt{classinfo} structure pointer, to indicate
+that the linker function did not raise an error or exception.
\section{Initialization}
+\label{sectioninitialization}
+
+A class or interface can have a \texttt{static} initialization
+function called \textit{static class initializer}. The function has
+the name \texttt{<clinit>()V}. This function must be invoked before a
+\texttt{static} function of the class is called or a \texttt{static}
+field is accessed via \texttt{ICMD\_PUTSTATIC} or
+\texttt{ICMD\_GETSTATIC}. In CACAO
+
+\begin{verbatim}
+ classinfo *class_init(classinfo *c);
+\end{verbatim}
+
+is responsible for the invocation of the \textit{static class
+initializer}. It is, like for class loading and class linking, just a
+wrapper function to the main initializing function
+
+\begin{verbatim}
+ static classinfo *class_init_intern(classinfo *c);
+\end{verbatim}
+
+The wrapper function has the following purposes:
+
+\begin{itemize}
+ \item enter a monitor on the \texttt{classinfo} structure, so that
+ only one thread can initialize the same class or interface at the
+ same time
+
+ \item check if the class or interface is \texttt{initialized} or
+ \texttt{initializing}, if one is \texttt{true}, leave the monitor and
+ return
+
+ \item tag the class or interface as \texttt{initializing}
+
+ \item call the internal initialization function
+ \texttt{class\_init\_intern}
+
+ \item if the internal initialization function returns
+ non-\texttt{NULL}, the class or interface is tagged as
+ \texttt{initialized}
+
+ \item reset the \texttt{initializing} flag
+
+ \item leave the monitor
+\end{itemize}
+
+The intern initializing function should not be called directly,
+because of race conditions of concurrent threads. Two or more
+different threads could access a \texttt{static} field or call a
+\texttt{static} function of an uninitialized class at almost the same
+time. This means that each single thread would invoke the
+\textit{static class initializer} and this would lead into some
+problems.
+
+The CACAO initializer needs to tag the class or interface as currently
+initializing. This is done by setting the \texttt{initializing} field
+of the \texttt{classinfo} structure to \texttt{true}. CACAO needs this
+field in addition to the \texttt{initialized} field for two reasons:
+
+\begin{itemize}
+ \item Another concurrently running thread can access a
+ \texttt{static} field of the currently initializing class or
+ interface. If the class or interface of the \texttt{static} field was
+ not initialized during code generation, some special code was
+ generated for the \texttt{ICMD\_PUTSTATIC} and
+ \texttt{ICMD\_GETSTATIC} intermediate commands. This special code is
+ a call to an architecture dependent assembler function named
+ \texttt{asm\_check\_clinit}. Since this function is speed optimized
+ for the case that the target class is already initialized, it only
+ checks for the \texttt{initialized} field and does not take care of
+ any monitor that may have been entered. If the \texttt{initialized}
+ flag is \texttt{false}, the assembler function calls the
+ \texttt{class\_init} function where it probably stops at the monitor
+ enter. Due to this fact, the thread which does the initialization can
+ not set the \texttt{initialized} flag to \texttt{true} when the
+ initialization starts, otherwise potential concurrently running
+ threads would continue their execution although the \textit{static
+ class initializer} has not finished yet.
+
+ \item The thread which is currently \texttt{initializing} the class
+ or interface can pass the monitor which has been entered and thus
+ needs to know if this class or interface is currently initialized.
+\end{itemize}
+
+Firstly \texttt{class\_init\_intern} checks if the passed class or
+interface is loaded and linked. If not, the particular action is
+taken. This is just a safety measure, because---CACAO
+internally---each class or interface should have been already loaded
+and linked before \texttt{class\_init} is called.
+
+Then the superclass, if any specified, is checked if it is already
+initialized. If not, the initialization is done immediately. The same
+check is performed for each interface in the \texttt{interfaces} array
+of the \texttt{classinfo} structure of the current class or interface.
+
+After the superclass and all interfaces are initialized, CACAO tries
+to find the \textit{static class initializer} function, where the
+method name matches \texttt{<clinit>} and the method descriptor
+\texttt{()V}. If no \textit{static class initializer} method is found in the
+current class or interface, the \texttt{class\_link\_intern} functions
+returns immediately without an error. If a \textit{static class
+initializer} method is found, it's called with the architecture
+dependent assembler function \texttt{asm\_calljavafunction}.
+
+Exception handling of an exception thrown in an \textit{static class
+initializer} is a bit different than usual. It depends on the type of
+exception. If the exception thrown is an instance of
+\texttt{java.lang.Error}, the \texttt{class\_init\_intern} function
+just returns \texttt{NULL}. If the exception thrown is an instance of
+\texttt{java.lang.Exception}, the exception is wrapped into a
+\texttt{java.lang.ExceptionInInitializerError}. This is done via the
+\texttt{new\_exception\_throwable} function call. The newly generated
+error is set as exception thrown and the \texttt{class\_init\_intern}
+returns \texttt{NULL}.
+
+If no exception occurred in the \textit{static class initializer}, the
+internal initializing function returns the current \texttt{classinfo}
+structure pointer to indicate, that the initialization was successful.
projects / cacao.git / blobdiff