harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ge...@apache.org
Subject svn commit: r448759 [6/8] - in /incubator/harmony/standard/site: ./ docs/ docs/documentation/ docs/subcomponents/buildtest/ docs/subcomponents/classlibrary/ docs/subcomponents/drlvm/ docs/subcomponents/jchevm/ docs/subcomponents/stresstest/ xdocs/ xdoc...
Date Fri, 22 Sep 2006 01:09:40 GMT
Modified: incubator/harmony/standard/site/docs/subcomponents/drlvm/developers_guide.html
URL: http://svn.apache.org/viewvc/incubator/harmony/standard/site/docs/subcomponents/drlvm/developers_guide.html?view=diff&rev=448759&r1=448758&r2=448759
==============================================================================
--- incubator/harmony/standard/site/docs/subcomponents/drlvm/developers_guide.html (original)
+++ incubator/harmony/standard/site/docs/subcomponents/drlvm/developers_guide.html Thu Sep 21 18:09:38 2006
@@ -36,7 +36,7 @@
             
             <title>Apache Harmony - Developers Guide</title>
 
-                                <link rel="Stylesheet" type="text/css" href="/harmony/site.css"/>
+                                <link rel="Stylesheet" type="text/css" href="site.css"/>
         </head>
 
         <body>        
@@ -204,7331 +204,7331 @@
                     <td width="80%" valign="top"><a name="top"></a>
                                         
                                                                 <div>
-<!--
-    Copyright 2005-2006 The Apache Software Foundation or its licensors, as applicable.
-
-    Licensed under the Apache License, Version 2.0 (the "License");
-    you may not use this file except in compliance with the License.
-    You may obtain a copy of the License at
-
-       http://www.apache.org/licenses/LICENSE-2.0
-
-    Unless required by applicable law or agreed to in writing, software
-    distributed under the License is distributed on an "AS IS" BASIS,
-    WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-    See the License for the specific language governing permissions and
-    limitations under the License.
-
-
--->
-<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
-"http://www.w3.org/TR/html4/loose.dtd">
-<html>
-   <head>
-      <meta http-equiv="Content-Type" content=
-      "text/html; charset=windows-1252">
-      <title>
-         Virtual Machine Developer&#39;s Guide
-      </title>
-      <link rel="Stylesheet" type="text/css" href="drl.css">
-
-   </head>
-   <body>
-    <p class="title">
-         <a name="Top"></a>Dynamic Runtime Layer Developer's Guide
-    <p class="TOCHeading"><a href="#Revision_History">Revision History</a>
-   </p>
-    <p class="TOCHeading"><a href="#Disclaimer">Disclaimer</a>
-   </p>
-    <p class="TOCHeading">
-         <a href="#About_this_document">1. About this Document</a>
-   </p>
-      <p class="TOC">
-         <a href="#Purpose">1.1 Purpose</a>
-      </p>
-      <p class="TOC">
-         <a href="#Intended_Audience">1.2 Intended Audience</a>
-      </p>
-      <p class="TOC">
-         <a href="#Using_this_document">1.3 Using This Document</a>
-      </p>
-      <p class="TOC">
-         <a href="#Conventions_and_Symbols">1.4 Conventions and Symbols</a>
-      </p>
-      <p class="TOCHeading">
-         <a href="#VM_Architecture">2. VM Architecture</a>
-      </p>
-      <p class="TOC">
-         <a href="#Overview">2.1 Overview</a>
-      </p>
-      <p class="TOC">
-         <a href="#Component_Structure">2.2 About Components</a>
-      </p>
-      <p class="TOC">
-         <a href="#major_components">2.3 Major DRL Components</a>
-      </p>
-      <p class="TOC">
-         <a href="#Data_Structures">2.4 Data Structures</a>
-      </p>
-      <p class="TOC">
-         <a href="#Initialization">2.5 Initialization</a>
-      </p>
-      <p class="TOC">
-         <a href="#Root_Set_Enumeration">2.6 Root Set Enumeration</a>
-      </p>
-      <p class="TOC">
-         <a href="#Finalization">2.7 Finalization</a>
-      </p>
-      <p class="TOCHeading">
-         <a href="#VM_Core">3. VM Core</a>
-      </p>
-      <p class="TOC">
-         <a href="#VMCore_architecture">3.1 Architecture</a>
-      </p>
-      <p class="TOC">
-         <a href="#Class_support">3.2 Class Support</a>
-      </p>
-      <p class="TOC">
-         <a href="#Native_Code_Support">3.3 Native Code Support</a>
-      </p>
-      <p class="TOC">
-         <a href="#Stack_Support">3.4 Stack Support</a>
-      </p>
-      <p class="TOC">
-         <a href="#Thread_Management">3.5 Thread Management</a>
-      </p>
-      <p class="TOC">
-         <a href="#Kernel_Classes">3.6 Kernel Classes</a>
-      </p>
-      <p class="TOC">
-         <a href="#Kernel_Class_Natives">3.7 Kernel Class Natives</a>
-      </p>
-      <p class="TOC">
-         <a href="#VM_Services">3.8 VM Services</a>
-      </p>
-      <p class="TOC">
-         <a href="#Exception_Handling">3.9 Exception Handling</a>
-      </p>
-      <p class="TOC">
-         <a href="#JVMTI_Support">3.10 JVMTI Support</a>
-      </p>
-      <p class="TOC">
-         <a href="#Verifier">3.11 Verifier</a>
-      </p>
-      <p class="TOC">
-         <a href="#Utilities">3.12 Utilities</a>
-      </p>
-      <p class="TOC">
-         <a href="#VM_exported_interfaces">3.13 Public Interfaces</a>
-      </p>
-      <p class="TOCHeading">
-         <a href="#JIT_Compiler">4. JIT Compiler</a>
-      </p>
-      <p class="TOC">
-         <a href="#JIT_architecture">4.1 Architecture</a>
-      </p>
-      <p class="TOC">
-         <a href="#Front-end">4.2 Front-end</a>
-      </p>
-      <p class="TOC">
-         <a href="#Optimizer">4.3 Optimizer</a>
-      </p>
-      <p class="TOC">
-         <a href="#Code_selector">4.4 Code Selector</a>
-      </p>
-      <p class="TOC">
-         <a href="#Back-end">4.5 IA-32 Back-end</a>
-      </p>
-      <p class="TOC">
-         <a href="#JIT_utilities">4.6 Utilities</a>
-      </p>
-      <p class="TOC">
-         <a href="#JIT_interfaces">4.7 Public Interfaces</a>
-      </p>
-      <p class="TOC">
-         <a href="#JET_introduction">4.8 Jitrino.JET</a>
-      </p>
-      <p class="TOCHeading">
-         <a href="#EM">5. Execution Manager</a>
-      </p>
-      <p class="TOC">
-         <a href="#EM_architecture">5.1 Architecture</a>
-      </p>
-      <p class="TOC">
-         <a href="#Recompilation">5.2 Recompilation Model</a>
-      </p>
-      <p class="TOC">
-         <a href="#PC">5.3 Profile Collector</a>
-      </p>
-      <p class="TOC">
-         <a href="#Profiler_thread">5.4 Profiler Thread</a>
-      </p>
-      <p class="TOC">
-         <a href="#EM_interfaces">5.5 Public Interfaces</a>
-      </p>
-      <p class="TOCHeading">
-         <a href="#GC">6. Garbage Collector</a>
-      </p>
-      <p class="TOC">
-         <a href="#GC_Architecture">6.1 Architecture</a>
-      </p>
-      <p class="TOC">
-         <a href="#GC_procedure">6.2 GC Procedure</a>
-      </p>
-      <p class="TOC">
-         <a href="#Object_Allocation">6.3 Object Allocation</a>
-      </p>
-      <p class="TOC">
-         <a href="#GC_Exported_Interfaces">6.4 Public Interfaces</a>
-      </p>
-      <p class="TOCHeading">
-         <a href="#Interpreter">7. Interpreter</a>
-      </p>
-      <p class="TOC">
-         <a href="#Characteristics_of_the_Interpreter">7.1 Characteristics</a>
-      </p>
-      <p class="TOC">
-         <a href="#Interpreter_structure">7.2 Internal Structure</a>
-      </p>
-      <p class="TOC">
-         <a href="#Interpreter_support_VM">7.3 Support Functions</a>
-      </p>
-      <p class="TOCHeading">
-         <a href="#Porting_Layer">8. Porting Layer</a>
-      </p>
-      <p class="TOC">
-         <a href="#Porting_Layer_Characteristics">8.1 Characteristics</a>
-      </p>
-      <p class="TOC">
-         <a href="#Component_Manager">8.2 Component Manager</a>
-      </p>
-      <p class="TOC">
-         <a href="#Portlib_exported">8.3 Public Interfaces</a>
-      </p>
-      <p class="TOCHeading">
-         <a href="#Class_Libraries">9. Class Libraries</a>
-      </p>
-      <p class="TOC">
-         <a href="#CL_characteristics">9.1 Characteristics</a>
-      </p>
-      <p class="TOC">
-         <a href="#CL_packaging_structure">9.2 Packaging Structure</a>
-      </p>
-      <p class="TOCHeading">
-         <a href="#Inter_component_Optimizations">10. Inter-component
-         Optimizations</a>
-      </p>
-      <p class="TOC">
-         <a href="#Fast_subtype_checking">10.1 Fast Subtype Checking</a>
-      </p>
-      <p class="TOC">
-         <a href="#Direct_call_conversion">10.2 Direct-call Conversion</a>
-      </p>
-      <p class="TOC">
-         <a href="#Fast_constant_string">10.3 Fast Constant-string
-         Instantiation</a>
-      </p>
-      <p class="TOC">
-         <a href="#Lazy_exceptions">10.4 Lazy Exceptions</a>
-      </p>
-      <p class="TOCHeading">
-         <a href="#References">11. References</a>
-      </p>
-      <h1>
-         <a name="Revision_History"></a>Revision History
-      </h1>
-      <table width="100%">
-         <tr>
-            <td class="TableHeading" width="25%">
-               Version
-            </td>
-            <td class="TableHeading" width="50%">
-               Version Information
-            </td>
-            <td class="TableHeading">
-               Date
-            </td>
-         </tr>
-         <tr>
-            <td class="TableCell" width="25%">
-               Initial version
-            </td>
-            <td class="TableCell">
-               Intel, Nadya Morozova: document created.
-            </td>
-            <td class="TableCell">
-               November 16, 2005
-            </td>
-         </tr>
-         <tr>
-            <td class="TableCell" width="25%">
-               Version 1.0
-            </td>
-            <td class="TableCell">
-               Intel, Nadya Morozova: document updated and expanded.
-            </td>
-            <td class="TableCell">
-               March 2, 2006
-            </td>
-         </tr>
-      </table>
-      <h1>
-         <a name="Disclaimer"></a>Disclaimer and Legal Information
-      </h1>
-      <p>
-         Copyright 2005-2006 The Apache Software Foundation or its licensors, as
-         applicable.
-      </p>
-      <p>
-         Licensed under the Apache License, Version 2.0 (the
-         &quot;License&quot;); you may not use this file except in compliance
-         with the License. You may obtain a copy of the License at
-
-         <a href=
-         "http://www.apache.org/licenses/LICENSE-2.0">http://www.apache.org/licenses/LICENSE-2.0</a>
-      </p>
-      <p>
-         Unless required by applicable law or agreed to in writing, software
-         distributed under the License is distributed on an &quot;AS IS&quot;
-         BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
-         implied. See the License for the specific language governing
-         permissions and limitations under the License.
-</p>
-      <p> Portions, Copyright &copy; 1991-2005 Unicode, Inc. The following applies to Unicode. <br>
-        <br>
-COPYRIGHT AND PERMISSION NOTICE</p>
-      <p>        Copyright &copy; 1991-2005 Unicode, Inc. All rights reserved. Distributed under the Terms of Use
-        in <a href="http://www.unicode.org/copyright.html"  target="_blank">http://www.unicode.org/copyright.html</a>.
-        Permission is hereby granted, free of charge, to any person obtaining a copy of the Unicode data files
-        and any associated documentation (the &quot;Data Files&quot;) or Unicode software and any associated documentation
-        (the &quot;Software&quot;) to deal in the Data Files or Software without restriction, including without limitation
-        the rights to use, copy, modify, merge, publish, distribute, and/or sell copies of the Data Files or Software,
-        and to permit persons to whom the Data Files or Software are furnished to do so, provided that
-        (a) the above copyright notice(s) and this permission notice appear with all copies of the Data Files or Software,
-        (b) both the above copyright notice(s) and this permission notice appear in associated documentation, and
-        (c) there is clear notice in each modified Data File or in the Software as well as in the documentation associated with
-        the Data File(s) or Software that the data or software has been modified.</p>
-      <p> THE DATA FILES AND SOFTWARE ARE PROVIDED &quot;AS IS&quot;, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED,
-        INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE
-        AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR HOLDERS INCLUDED
-        IN THIS NOTICE BE LIABLE FOR ANY CLAIM, OR ANY SPECIAL INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER
-        RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
-        ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THE DATA FILES OR SOFTWARE.</p>
-      <p> Except as contained in this notice, the name of a copyright holder shall not be used in advertising or otherwise
-        to promote the sale, use or other dealings in these Data Files or Software without prior written authorization
-        of the copyright holder.</p>
-      <p> 2. Additional terms from the Database:</p>
-      <p>Copyright &copy; 1995-1999 Unicode, Inc. All Rights reserved.</p>
-      <p>Disclaimer </p>
-      <p> The Unicode Character Database is provided as is by Unicode, Inc. No claims are made as to fitness for
-        any particular purpose. No warranties of any kind are expressed or implied. The recipient agrees to determine
-        applicability of information provided. If this file has been purchased on magnetic or optical media from Unicode, Inc.,
-        the sole remedy for any claim will be exchange of defective media within 90 days of receipt.
-        This disclaimer is applicable for all other data files accompanying the Unicode Character Database,
-        some of which have been compiled by the Unicode Consortium, and some of which have been supplied by other sources.</p>
-      <p> Limitations on Rights to Redistribute This Data</p>
-      <p> Recipient is granted the right to make copies in any form for internal distribution and to freely use
-        the information supplied in the creation of products supporting the Unicode<sup>TM</sup> Standard.
-        The files in the Unicode Character Database can be redistributed to third parties or other organizations
-        (whether for profit or not) as long as this notice and the disclaimer notice are retained.
-        Information can be extracted from these files and used in documentation or programs, as long as there is
-        an accompanying notice indicating the source. </p>
-      <h1>
-         <a name="About_this_document"></a>1. About This Document
-      </h1>
-      <h2>
-         <a name="Purpose"></a>1.1 Purpose
-      </h2>
-      <p>
-         This document introduces DRL, the dynamic run-time layer, explains
-         basic concepts and terms, and gives an overview of the product&#39;s
-         structure and interfaces for inter-component communication. Special
-         focus is given to the virtual machine, DRLVM. Use this document to
-         focus on the DRLVM implementation specifics and to understand the
-         internal peculiarities of the product.
-</p>
-      <p>The document describes version 1 of the DRL virtual machine donated in March 2006. </p>
-      <h2>
-         <a name="Intended_Audience"></a>1.2 Intended Audience
-      </h2>
-      <p>
-         The target audience for the document includes a wide community of
-         engineers interested in using DRLVM and in working further with the
-         product to contribute to its development.
-      </p>
-      <h2>
-         <a name="Using_this_document"></a>1.3 Using This Document
-      </h2>
-      <p>
-         This document consists of several major parts describing the key
-         processes and components of the DRL virtual machine, as follows:
-      </p>
-      <p>
-         <a href="#VM_Architecture">Part 2. VM Architecture</a> provides an
-         overview of the DRL component-based model and describes the major
-         inter-component processes running inside the virtual machine, such as
-         <a href="#Root_Set_Enumeration">root set enumeration</a> and <a href=
-         "#Finalization">object finalization</a>. The part also comprises a
-         section about <a href="#Data_Structures">data structures</a> used in
-         DRLVM. You can start with this part to learn about major principles of
-         VM internal operation.
-      </p>
-      <p>
-         <a href="#VM_Core">Part 3. VM Core</a> gives an in-depth description
-         of the core virtual machine and its subcomponents responsible for
-         various functions of the virtual machine, including <a href=
-         "#Stack_Walking">stack walking</a> and <a href=
-         "#Thread_Management">thread management</a>.
-      </p>
-      <p>
-         <a href="#JIT_Compiler">Part 4. JIT Compiler</a> describes compilation
-         paths and specific features of the DRL just-in-time compiler. Consult
-         this part of the guide for details on optimizations implemented in the
-         DRL JIT compiler and its code generation path.
-      </p>
-      <p>
-         <a href="#EM">Part 5. Execution Manager</a> shows the details of the
-         dynamic profile-guided optimization subsystem. In this part, you can
-         find information on method profiles and recompilation logic.
-      </p>
-      <p>
-         <a href="#GC">Part 6. Garbage Collector</a> focuses on object
-         allocation and garbage collection processes. This part contains a
-         description of the garbage collector component and of its interaction
-         with the VM core.
-      </p>
-      <p>
-         <a href="#Interpreter">Part 7. Interpreter</a> has a description of
-         the interpreter component and its debugging services.
-      </p>
-      <p>
-         <a href="#Porting_Layer">Part 8. Porting Layer</a> gives an overview
-         of platform-dependent functionality used in DRL. The part also
-         includes an overview of the <a href="#Component_Manager">component
-         manager</a>.
-      </p>
-      <p>
-         <a href="#Class_Libraries">Part 9. Class Libraries</a> gives
-         information on the layout and characteristics of the Java<a href=
-         "#*">*</a> class libraries interacting with the DRL virtual machine.
-      </p>
-      <p>
-         <a href="#Inter_component_Optimizations">Part 10. Inter-component
-         Optimizations</a> is devoted to performance-improving operations that
-         involve multiple components.
-      </p>
-      <p>
-         <a href="#References">Part 11. References</a> lists the links to
-         external materials supporting this document. These materials include
-         specifications, manual on programming, and articles on specific
-         issues. You can consult this part of the document for directions on
-         investigating a specific problem or alternative ways of implementing
-         specific features.
-      </p>
-      <p class="backtotop">
-         <a href="#Top">Back to Top</a>
-      </p>
-      <h2>
-         <a name="Conventions_and_Symbols"></a>1.4 Conventions and Symbols
-      </h2>
-      <p>
-         This document uses the <a href="conventions.htm">unified
-         conventions</a> for the DRL documentation kit.
-      </p>
-      <p>
-         The table below provides the definitions of all acronyms used in the
-         document.
-      </p>
-      <table class="normalTable" border="0" cellpadding="0" width="100%">
-         <tr>
-            <td class="TableHeading">
-               Acronym
-            </td>
-            <td class="TableHeading">
-               Definition
-            </td>
-         </tr>
-         <tr>
-            <td class="TableCell">
-               API
-            </td>
-            <td class="TableCell">
-               Application Program Interface
-            </td>
-         </tr>
-         <tr>
-            <td class="TableCell">
-               APR
-            </td>
-            <td class="TableCell">
-               Apache Portable Runtime Layer
-            </td>
-         </tr>
-         <tr>
-            <td class="TableCell">
-               CFG
-            </td>
-            <td class="TableCell">
-               Control Flow Graph
-            </td>
-         </tr>
-         <tr>
-            <td class="TableCell">
-               CG
-            </td>
-            <td class="TableCell">
-               Code Generator
-            </td>
-         </tr>
-         <tr>
-            <td class="TableCell">
-               CLI
-            </td>
-            <td class="TableCell">
-               Common Language Interface
-            </td>
-         </tr>
-         <tr>
-            <td class="TableCell">
-               DFG
-            </td>
-            <td class="TableCell">
-               Data Flow Graph
-            </td>
-         </tr>
-         <tr>
-            <td class="TableCell" height="40">
-               DPGO
-            </td>
-            <td class="TableCell" height="40">
-               Dynamic Profile-guided Optimizations
-            </td>
-         </tr>
-         <tr>
-            <td class="TableCell">
-               DRL
-            </td>
-            <td class="TableCell">
-               Dynamic Run-time Layer
-            </td>
-         </tr>
-         <tr>
-            <td class="TableCell">
-               DRLVM
-            </td>
-            <td class="TableCell">
-               Dynamic Run-time Layer Virtual Machine
-            </td>
-         </tr>
-         <tr>
-            <td class="TableCell">
-               EE
-            </td>
-            <td class="TableCell">
-               Execution Engine
-            </td>
-         </tr>
-         <tr>
-            <td class="TableCell">
-               EM
-            </td>
-            <td class="TableCell">
-               Execution Manager
-            </td>
-         </tr>
-         <tr>
-            <td class="TableCell">
-               FP
-            </td>
-            <td class="TableCell">
-               Floating Point
-            </td>
-         </tr>
-         <tr>
-            <td class="TableCell">
-               GC
-            </td>
-            <td class="TableCell">
-               Garbage Collector
-            </td>
-         </tr>
-         <tr>
-            <td class="TableCell">
-               HIR
-            </td>
-            <td class="TableCell">
-               High-level Intermediate Representation
-            </td>
-         </tr>
-         <tr>
-            <td class="TableCell">
-               IR
-            </td>
-            <td class="TableCell">
-               Intermediate Representation
-            </td>
-         </tr>
-         <tr>
-            <td class="TableCell">
-               J2SE<a href="#*">*</a>
-            </td>
-            <td class="TableCell">
-               Java<a href="#*">*</a> 2 Standard Edition
-            </td>
-         </tr>
-         <tr>
-            <td class="TableCell">
-               JCL
-            </td>
-            <td class="TableCell">
-               Java<a href="#*">*</a> Class Libraries
-            </td>
-         </tr>
-         <tr>
-            <td class="TableCell">
-               JIT
-            </td>
-            <td class="TableCell">
-               Just-in-time Compiler
-            </td>
-         </tr>
-         <tr>
-            <td class="TableCell">
-               JNI
-            </td>
-            <td class="TableCell">
-               Java<a href="#*">*</a> Native Interface
-            </td>
-         </tr>
-         <tr>
-            <td class="TableCell">
-               JVM
-            </td>
-            <td class="TableCell">
-               Java<a href="#*">*</a> Virtual Machine
-            </td>
-         </tr>
-         <tr>
-            <td class="TableCell">
-               JVMTI
-            </td>
-            <td class="TableCell">
-               JVM Tool Interface
-            </td>
-         </tr>
-         <tr>
-            <td class="TableCell">
-               LIR
-            </td>
-            <td class="TableCell">
-               Low-level Intermediate Representation
-            </td>
-         </tr>
-         <tr>
-            <td class="TableCell">
-               LMF
-            </td>
-            <td class="TableCell">
-               Last Managed Frame
-            </td>
-         </tr>
-         <tr>
-            <td class="TableCell">
-               LOB
-            </td>
-            <td class="TableCell">
-               Large Object Block
-            </td>
-         </tr>
-         <tr>
-            <td class="TableCell">
-               LOS
-            </td>
-            <td class="TableCell">
-               Large Object Space
-            </td>
-         </tr>
-         <tr>
-            <td class="TableCell">
-               OS
-            </td>
-            <td class="TableCell">
-               Operating System
-            </td>
-         </tr>
-         <tr>
-            <td class="TableCell">
-               PC
-            </td>
-            <td class="TableCell">
-               Profile Collector
-            </td>
-         </tr>
-         <tr>
-            <td class="TableCell">
-               SIMD
-            </td>
-            <td class="TableCell">
-               Single Instruction Multiple Data
-            </td>
-         </tr>
-         <tr>
-            <td class="TableCell">
-               SOB
-            </td>
-            <td class="TableCell">
-               Single Object Block
-            </td>
-         </tr>
-         <tr>
-            <td class="TableCell">
-               SSA
-            </td>
-            <td class="TableCell">
-               Single Static Assignment
-            </td>
-         </tr>
-         <tr>
-            <td class="TableCell">
-               SSE, SSE2
-            </td>
-            <td class="TableCell">
-               Streaming SIMD Extensions (2)
-            </td>
-         </tr>
-         <tr>
-            <td class="TableCell">
-               STL
-            </td>
-            <td class="TableCell">
-               Standard Template Library
-            </td>
-         </tr>
-         <tr>
-            <td class="TableCell">
-               TBS
-            </td>
-            <td class="TableCell">
-               Time-based Sampling
-            </td>
-         </tr>
-         <tr>
-            <td class="TableCell">
-               TLS
-            </td>
-            <td class="TableCell">
-               Thread Local Storage
-            </td>
-         </tr>
-         <tr>
-            <td class="TableCell">
-               TM
-            </td>
-            <td class="TableCell">
-               Thread Manager
-            </td>
-         </tr>
-         <tr>
-            <td class="TableCell">
-               VM
-            </td>
-            <td class="TableCell">
-               Virtual Machine, same as JVM in current document
-            </td>
-         </tr>
-      </table>
-      <p class="backtotop">
-         <a href="#Top">Back to Top</a>
-      </p>
-      <h1>
-         <a name="VM_Architecture"></a>2. VM Architecture
-      </h1>
-      <h2>
-         <a name="Overview"></a>2.1 Overview
-      </h2>
-      <p>
-         The Dynamic Runtime Layer (DRL) is a clean-room implementation of the
-         Java<a href="#*">*</a> 2 Platform, Standard Edition (J2SE<a href=
-         "#*">*</a>) 1.5.0. This Java<a href="#*">*</a> run-time environment
-         consists of the virtual machine (DRLVM), and a set of Java<a href=
-         "#*">*</a> class libraries (JCL). The product is released in open
-         source. The virtual machine is written in C++ code and a small amount
-         of assembly code. This document focuses on the virtual machine, and
-         gives a short overview of the class libraries supporting it.
-      </p>
-      <p>
-         Key features of DRL include the following:
-      </p>
-      <ul>
-         <li>
-            <i>Modularity</i>: Functionality is grouped into a limited number
-            of coarse-grained modules with well defined interfaces.
-
-         <li>
-            <i>Pluggability</i>: Module implementations can be replaced at
-            compile time or run time. Multiple implementations of a given
-            module are possible.
-
-         <li>
-            <i>Consistency</i>: Interfaces are consistent across platforms.
-
-         <li>
-            <i>Performance</i>: Interfaces fully enable implementation of
-            modules optimized for specific target platforms.
-
-      </ul>
-      <h2>
-         <a name="Component_Structure"></a>2.2 About Components
-      </h2>
-      <p>
-         The DRL virtual machine reconciles high performance with the extensive
-         use of well-defined interfaces between its components.
-      </p>
-      <h3><a name="CompInterfInst"></a>
-         2.2.1 Components, Interfaces, and Instances
-      </h3>
-      <p>
-         A <em>component</em> corresponds to one static or dynamic library, and
-         several libraries linked statically or dynamically at run time make up
-         the managed run-time environment. For details on components linking,
-         see section <a href="#linking_models">2.2.2 Linking Models</a>.
-      </p>
-      <p>
-         DRLVM components communicate via functional interfaces. An
-         <em>interface</em> is a pointer to a table of function pointers to
-         pure C methods. Interfaces have string names, which unambiguously
-         identify their function table layout. Each component exposes the
-         <em>default interface</em> to communicate with the <a href=
-         "#Component_Manager">component manager</a>, and one or more interfaces
-         for communication with other components.
-      </p>
-      <p class="note">
-         Note
-      </p>
-      <p class="notetext">
-         In the current version, only the <a href="#EM">execution manager</a> uses the component
-         manager. Other components will migrate to this new model in further
-         releases.
-      </p>
-      <p>
-         DRL can also operate with co-existing component instances, as requires
-         the Invocation API [<a href="#Invoc_api_ref">7</a>]. An
-         <em>instance</em> of a component contains a pointer to its default
-         interface and
-         component-specific data. The <a href="#Porting_Layer">porting layer</a>
-         always has exactly one instance. This allows a compiler to in-line
-         calls to the porting layer functions. Other components have the same
-         number of instances as the VM core does.
-      </p>
-      <p class="class">
-         Background
-      </p>
-      <p class="notetext">
-         In Java<a href="#*">*</a> programming, components, interfaces, and
-         instances can be described in terms of classes, interfaces and
-         objects. A VM component encapsulates common features, attributes, and
-         properties of virtual machines, and maps to a Java<a href="#*">*</a>
-         class. VM interfaces are tables of methods implemented and exposed by
-         the class. If several virtual machines exist in the same address
-         space, they all expose the same interfaces. These VM instances are
-         instances of the VM class, or objects.<br>
-          The <a href="#Component_Manager">component manager</a> enables
-         explicit creation of component instances by exposing the
-         <code>CreateNewInstance()</code> function, which corresponds to the
-         Java<a href="#*">*</a> operator <code>new()</code>. Components with
-         only one instance correspond to static class methods in Java<a href=
-         "#*">*</a>. All components are initialized at load time.
-      </p>
-      <p>
-         Subsequent sections define each component and provide information on
-         public interfaces, dependencies and other component specifics.
-      </p>
-      <h3>
-         <a name="linking_models"></a>2.2.2 Linking Models
-      </h3>
-      <p>
-         Libraries corresponding to different DRL components are linked by one
-         of the following models:
-      </p>
-      <ul>
-         <li>
-            Unconditionally required components, such as the porting layer, are
-            plugged at the source level and linked statically to the main
-            executable. The same applies to the code that loads other
-            components, see section <a href="#Component_Manager">8.2 Component
-            Manager</a>.
-
-         <li>
-            Components required by the VM configuration, such as a specific
-            garbage collector or a JIT compiler, are loaded at run time based
-            on the configuration settings. For example, the virtual machine on
-            a multiprocessor system can load a more complex garbage collector
-            that takes advantage of parallel processing.
-
-         <li>
-            Third-party components shipped as dynamic libraries, such as the
-            <a href="#Memory_Management">memory manager</a>, are also loaded at run time.
-
-      </ul>
-      <p class="backtotop">
-         <a href="#Top">Back to Top</a>
-      </p>
-      <h2>
-         <a name="major_components"></a>2.3 Major DRL Components
-      </h2>
-      <p>
-         Figure 1 below displays the major DRL components and their interfaces.
-      </p>
-      <p align="center">
-         <img src="images/DRL_structure.gif" alt="Major DRL Components" border=
-         "0">
-      </p>
-      <p class="special">
-         <a name="FigureDRLComponents"></a>Figure 1. Major DRL Components
-      </p>
-      <p>
-         Figure 1 demonstrates the DRL Java<a href="#*">*</a> virtual machine
-         major components, and the class libraries that support the machine.
-         These components are responsible for the following functions:
-      </p>
-      <ul>
-         <li>
-            <a href="#Class_Libraries">Class libraries</a> include a set of
-            classes and interfaces that constitute the application programming
-            interface (API) for the Java<a href="#*">*</a> run-time
-            environment. The Java<a href="#*">*</a> class libraries (JCL)
-            complement the virtual machine to make up the Dynamic Runtime
-            Layer.
-            <p>
-               The other components listed below make part of the DRL virtual
-               machine.
-            </p>
-
-         <li>
-            <a href="#VM_Core">VM core</a> with its subcomponents concentrates
-            most JVM control functions.
-
-         <li>
-            <i>Execution engine</i> is the generic term for components that
-            execute bytecode or prepare it for execution. DRLVM
-            currently features the following execution engines:
-            <ul>
-               <li>
-                  The <a href="#JIT_Compiler">Jitrino.opt</a> optimizing JIT
-                  compiler, which compiles code keeping reasonable balance
-                  between compilation time and quality of the generated code.
-
-               <li>
-                  The <a href="#JET_introduction">Jitrino.JET</a> just-in-time
-                  compiler aimed to fast bytecode compilation with almost no
-                  optimizations. Jitrino.JET uses the same interfaces and is
-                  packaged in the same dynamic library as the optimizing
-                  compiler.
-
-               <li>
-                  The <a href="#Interpreter">Interpreter</a> for easier
-                  debugging.
-
-            </ul>
-
-        <li>
-            <a href="#EM">Execution manager</a> selects the execution engine
-            for compiling a method, handles profiles and the dynamic
-            recompilation logic.
-
-        <li>
-            <a href="#GC">Garbage collector</a> allocates Java<a href=
-            "#*">*</a> objects in the heap memory and reclaims unreachable
-            objects by using the <a href="#GC_procedure">mark sweep and compaction</a> algorithm.
-
-        <li>
-            <a href="#Porting_Layer">Porting layer</a> hides platform-specific
-            details from other VM components behind a single interface. In the
-            current implementation, the porting layer is based on the Apache
-            Portable Runtime layer [<a href="#APR_ref">14</a>].
-
-      </ul>
-      <p>
-         Depending on the configuration, you can use multiple execution engine
-         components, for example, an interpreter and optimizing JIT.
-         Simultaneous use of multiple JIT compilers can provide different
-         trade-offs between compilation time and code quality.
-      </p>
-      <p class="backtotop">
-         <a href="#Top">Back to Top</a>
-      </p>
-      <h2>
-         <a name="Data_Structures"></a>2.4 Data Structures
-      </h2>
-      <p>
-         This section provides an overview of data structures in DRLVM, typical
-         examples of data structures, and the exposed data layout of public
-         data structures.
-      </p>
-      <p>
-         In DRLVM, all data structures are divided into the following groups:
-      </p>
-      <ul>
-         <li>
-            <i>Private</i> data structures can only be used inside a specific DRLVM component.
-			Other components can only access such data structures via exported component interfaces.
-         <li>
-            <i>Public</i> data structures shared across different DRLVM
-            components as listed in this section.
-
-      </ul>
-      <p>
-         For example, when compiling an access operation to an instance field,
-         the JIT calls the public <code>VM_JIT</code> interface function to
-         obtain the offset, and uses the result to generate the appropriate
-         load instruction. Another example is the VM core internal
-         representation of a class object.
-      </p>
-      <h3>
-         <a name="object_layout"></a>2.4.1 Object Layout
-      </h3>
-      <p>
-         DRLVM exports data structures in accordance with the JNI [<a href=
-         "#JNI_ref">5</a>] and JVMTI [<a href="#JVMTI_ref">4</a>] standards. In
-         addition to these structures, DRLVM shares information about an object
-         layout across its components. In particular, the Java Native Interface
-         does not specify the structure of <code>jobject</code>, and DRLVM
-         defines it as illustrated below.
-      </p>
-      <pre>
-typedef struct ManagedObject {
-  VTable *vt;
-  uint32 obj_info;
-  /* Class-specific data */
-} ManagedObject;
-struct _jobject { ManagedObject* object; }
-typedef struct _jobject*  jobject;
-</pre>
-      <p>
-         The <code>jobject</code> structure contains the following elements:
-      </p>
-      <ul>
-         <li>
-            The <code>vt</code> field points to the object virtual-method
-            table.
-            <p>
-               <a name="vtable"></a>Each class has one <i>virtual-method
-               table</i> (VTable) with class-specific information to perform
-               common operations, such as getting pointers to virtual methods.
-               The VTable is shared across all instances of a class. During garbage
-               collection, the VTable supplies such information, as the size of
-               the object and the offset of each reference stored in the
-               instance.
-            </p>
-
-         <li>
-            The <code>obj_info</code> field is used during synchronization and
-            garbage collection. This is a 32-bit value on all supported
-            architectures. This field also stores the hash code of an instance.
-
-      </ul>
-      <p>
-         Class-specific instance fields immediately follow the <code>vt</code>
-         and <code>obj_info</code> fields. Representation of array instances is
-         shared between the garbage collector and the JIT compiler. The VM core
-         determines the specific offsets to store the array length and the
-         first element of the array. This way, the VM core makes these fields
-         available for the garbage collector and the JIT via the VM interface.
-      </p>
-      <dl>
-         <dt>
-            Example
-         </dt>
-         <dd>
-            The excerpt of code below illustrates the usage of an object
-            structure in DRLVM for the <code>GetBooleanField()</code> JNI
-            function.
-         </dd>
-      </dl>
-<pre>
-typedef jobject ObjectHandle;
-
-jboolean JNICALL GetBooleanField(JNIEnv *env,
-                                 jobject obj,
-                                 jfieldID fieldID)
-{
-    Field *f = (Field *) fieldID;
-    /* Initialize the class if the field is accessed */
-    if (!ensure_initialised(env, f-&gt;get_class())) {
-        return 0; /* Error */
-    }
-
-    ObjectHandle h = (ObjectHandle) obj;
-
-    tmn_suspend_disable();       //-- Do not allow GC suspension --v
-    Byte *java_ref = (Byte *)h-&gt;object;
-    jboolean val = *(jboolean *)(java_ref + offset);
-    tmn_suspend_enable();        //--------------------------------^
-
-    return val;
-} // GetBooleanField
-</pre>
-      <h3>
-         <a name="compressed_references"></a>2.4.2 Compressed References
-      </h3>
-      <p>
-         To decrease memory footprint on 64-bit platforms [<a href=
-         "#compres_ref">11</a>], direct object and VTable pointers are
-         compressed in the Java<a href="#*">*</a> heap to 32-bit values.
-      </p>
-      <p>
-         To calculate a direct heap pointer, the system adds the pointer to the
-         heap base to the compressed value from the reference field. Similarly,
-         a direct pointer to an object VTable equals to the compressed value
-         stored in the first 32 bits of the object plus the base VTable
-         pointer. This limits the maximum heap size to 4 GB, but significantly
-         reduces the average object size and the work set size, and improves
-         cache performance.
-      </p>
-      <p>
-         Apart from the basic assumptions about object layout and the VTable
-         cache, all interaction between major DRLVM components is achieved
-         through function calls.
-      </p>
-      <p class="backtotop">
-         <a href="#Top">Back to Top</a>
-      </p>
-      <h2>
-         <a name="Initialization"></a>2.5 Initialization
-      </h2>
-      <p>
-         VM initialization is a sequence of operations performed at the virtual
-         machine start-up before execution of user applications. Currently,
-         DRLVM does not support the invocation API [<a href=
-         "#Invoc_api_ref">7</a>], and initialization follows the sequence
-         described below. The subsection <a href="#destroying_vm">2.5.3
-         Destroying the VM</a> below also describes the virtual machine
-         shutdown sequence.
-      </p>
-      <p>
-         The <code>main(&hellip;)</code> function is responsible for the major
-         stages of initialization sequence and does the following:
-      </p>
-      <ol>
-         <li>
-            Initializes the logger
-
-         <li>
-            Performs the first pass arguments parsing
-
-         <li>
-            Creates a VM instance by calling the <code>create_vm()</code>
-            function
-
-         <li>
-            Runs the user application by calling the <a href=
-            "#vmstarterstart"><code>VMStarter.start()</code></a> method
-
-         <li>
-            Destroys the VM instance by calling the <code>destroy_vm()</code>
-            function
-
-      </ol>
-      <p>
-         The subsequent sections describe these initialization stages in
-         greater detail.
-      </p>
-      <h3><a name="1stPass"></a>
-         2.5.1 First pass Arguments Parsing
-      </h3>
-      <p>
-         At this stage, the VM splits all command-line arguments into the
-         following groups:
-      </p>
-      <ul>
-         <li>
-            <code>&lt;vm-arguments&gt;</code> for initializing the VM instance
-
-         <li>
-            <code>&lt;class-name | -jar jar-file&gt;</code> for the name or
-            class or <code>.jar</code> file
-
-         <li>
-            <code>&lt;java-arguments&gt;</code> for the user application
-
-      </ul>
-      <p>
-         The virtual machine then creates the <code>JavaVMInitArgs</code>
-         structure from <code>&lt;vm-arguments&gt;</code>.
-      </p>
-      <h3><a name="creating_vm"></a>
-         2.5.2 Creating the VM
-      </h3>
-      <p>
-         The <code>create_vm()</code> function is a prototype for
-         <code>JNI_CreateJavaVM()</code> responsible for creating and
-         initializing the virtual machine. This function does the following:
-      </p>
-      <ol>
-         <li value="0">
-            For Linux<a href="#*">*</a> platforms, initializes the threading
-            system.<br>
-             No actions are performed on Windows<a href="#*">*</a> platforms.
-            Other steps apply to both operating systems.
-
-         <li>
-            Attaches the current thread. This is the first step of the
-            three-step procedure of attaching the thread to the VM. See steps
-            15 and 19 for further steps of the attaching procedure.
-              <ol>
-               <li>
-                  Creates synchronization objects.
-
-               <li>
-                  Initializes the <code>VM_thread</code> structure and stores
-                  the structure in the thread local storage.
-
-            </ol>
-
-         <li>
-            Initializes the VM global synchronization locks.
-
-         <li>
-            Creates the component manager.
-
-         <li>
-            Loads the garbage collector and interpreter libraries.
-
-         <li>
-            Initializes basic VM properties, such as <code>java.home</code>,
-            <code>java.library.path</code>, and
-            <code>vm.boot.class.path</code>, according to the location of the
-            VM library.<br>
-             The list of boot class path <code>.jar</code> files is hard-coded
-            into the VM library. Use <code>&ndash;Xbootclasspath</code>
-            command-line options to change the settings.
-
-         <li>
-            Initializes system signal handlers.
-
-         <li>
-            Parses VM arguments.
-
-         <li>
-            Initializes JIT compiler instances.
-
-         <li>
-            Initializes the VM memory allocator.
-
-         <li>
-            Initializes the garbage collector by calling <a href=
-            "#gc_init"><code>gc_init()</code></a>.
-
-         <li>
-            Preloads basic API native code dynamic libraries.
-            <p class="note">
-               Note
-            </p>
-            <p class="notetext">
-               The <code>vm.other_natives_dlls</code> property defines the list
-               of libraries to be loaded.
-            </p>
-
-         <li>
-            Initializes the JNI support VM core component.
-
-         <li>
-            Initializes the JVMTI support functionality, loads agent dynamic
-            libraries. At this step, the <em>primordial phase</em> starts.
-
-         <li>
-            Attaches the current thread and creates the <a href=
-            "#M2nFrame">M2nFrame</a> at the top of the stack (step 2).
-
-         <li>
-            Initializes the bootstrap class loader.
-
-         <li>
-            Preloads the classes required for further VM operation.
-
-         <li>
-            Caches the class handles for the core classes into the VM
-            environment.
-
-         <li>
-            Attaches the current thread (step 3).
-            <ol>
-               <li>
-                  Creates the <code>java.lang.Thread</code> object for the
-                  current thread.
-
-               <li>
-                  Creates the thread group object for the main thread group and
-                  includes the main thread in this group.
-
-               <li>
-                  Sets the system class loader by calling
-                  <code>java.lang.ClassLoader.getSystemClassLoader()</code>.
-
-            </ol>
-
-         <li>
-            Sends the <code>VMStart</code> JVMTI event. This step begins the
-            <em>start phase</em>.
-
-         <li>
-            Sends the <code>ThreadStart</code> JVMTI event for the main thread.
-            Send the <code>VMInit</code> JVMTI event. At this stage, the
-            <em>live phase</em> starts.
-
-         <li>
-            Calls the <a href=
-            "#vmstarterinit"><code>VMStarter.initialize()</code></a> method.
-
-      </ol>
-      <h3>
-         <a name="destroying_vm"></a>2.5.3 Destroying the VM
-      </h3>
-      <p>
-         The <code>destroy_vm()</code> function is a prototype for
-         <code>JNI_DestroyJavaVM()</code> responsible for terminating operation
-         of a VM instance. This function calls the <a href=
-         "#vmstartershutdown"><code>VMStarter.shutdown()</code></a> method.
-      </p>
-      <h3><a name="VMStarter"></a>
-         2.5.4 VMStarter class
-      </h3>
-      <p>
-         This Java<a href="#*">*</a> class supports specific VM core tasks by
-         providing the following methods:
-      </p>
-      <dl>
-         <dt>
-            <a name="vmstarterinit"></a>initialize()
-         </dt>
-         <dd>
-            Called by the <code>create_vm()</code> method, does the following:
-            <ul>
-               <li>
-                  Starts the finalizer and execution manager helper threads
-
-               <li>
-                  Registers the shutdown hook for proper helper threads
-                  shutdown
-
-            </ul>
-         </dd>
-         <dt>
-            <a name="vmstartershutdown"></a>shutdown()
-         </dt>
-         <dd>
-            Called by the <code>destroy_vm()</code> method, does the following:
-
-            <ul>
-               <li>
-                  Waits for non-daemon threads
-
-               <li>
-                  Calls the <code>System.exit()</code> method
-
-            </ul>
-         </dd>
-         <dt>
-            <a name="vmstarterstart"></a>start()
-         </dt>
-         <dd>
-            Runs the user application:
-            <ul>
-               <li>
-                  Initializes the system class loader
-
-               <li>
-                  Loads the main class of the application
-
-               <li>
-                  Obtains the <code>main()</code> method via reflection
-
-               <li>
-                  Starts the thread that invokes the <code>main()</code> method
-                  and caches exceptions from this method
-
-            </ul>
-         </dd>
-      </dl>
-      <p class="backtotop">
-         <a href="#Top">Back to Top</a>
-      </p>
-      <h2>
-         <a name="Root_Set_Enumeration"></a>2.6 Root Set Enumeration
-      </h2>
-      <p>
-         DRLVM automatically manages the Java<a href="#*">*</a> heap by using
-         tracing collection techniques.
-      </p>
-      <h3>
-         2.6.1 About Roots
-      </h3>
-      <p>
-         <em>Root set enumeration</em> is the process of collecting the initial
-         set of references to live objects, the <em>roots</em>. Defining the
-         root set enables the garbage collector to determine a set of all
-         objects directly reachable from the all running threads and to reclaim
-         the rest of the heap memory. The set of all live objects includes
-         objects referred by roots and objects referred by other live objects.
-         This way, the set of all live objects can be constructed by means of
-         transitive closure of the objects referred by the root set.
-      </p>
-      <p>
-         Roots consist of:
-      </p>
-      <ul>
-         <li>
-            Global references, such as static fields of classes, JNI global handles,
-            interned string references
-         <li>
-            Thread-specific references in managed stack frames, local JNI
-            handles, and the per-thread data structures maintained by the VM
-            core
-
-      </ul>
-      <h3>
-         2.6.2 Black-box Method
-      </h3>
-      <p>
-         In DRLVM, the <em>black-box method</em> is designed to accommodate
-         precise enumeration of the set of root references. The GC considers
-         everything outside the Java<a href="#*">*</a> heap as a black box, and
-         has little information about the organization of the virtual machine.
-         The GC relies on the support of the VM core to enumerate the root set.
-         In turn, the VM considers the thread stack as the black box, and uses
-         the services provided by the JIT and interpreter to iterate over the
-         stack frames and enumerate root references in each stack frame.
-      </p>
-      <p>
-         Enumeration of a method stack frame is best described in terms of safe
-         points and GC maps. <a name="GC_map"></a>The <em>GC map</em> is the
-         data structure for finding all live object pointers in the stack
-         frame. Typically, the GC map contains the list of method arguments and
-         local variables of the reference type, as well as spilt over
-         registers, in the form of offsets from the stack pointer. The GC map
-         is associated with a specific point in the method, the <em>safe
-         point</em>. The JIT determines the set of safe points at the method
-         compilation time, and the interpreter does this at run time. This way,
-         call sites and backward branches enter the list. During method
-         compilation, the JIT constructs the GC maps for each safe point. The
-         interpreter does not use stack maps, but keeps track of object
-         references dynamically, at run time. With the black-box method, the VM
-         has little data on the thread it needs to enumerate, only the register
-         context.
-      </p>
-      <p class="backtotop">
-         <a href="#Top">Back to Top</a>
-      </p>
-      <h3>
-         2.6.3 Enumeration Procedure
-      </h3>
-      <p>
-         When the GC decides to do garbage collection, it enumerates all roots
-         as described below.
-      </p>
-      <ol>
-         <li>
-            The garbage collector calls the VM core function
-            <code>vm_enumerate_root_set_all_threads()</code>.
-            <p class="note">
-               Note
-            </p>
-            <p class="notetext">
-               Currently, the DRLVM implementation does not support concurrent
-               garbage collectors.
-            </p>
-
-         <li>The
-            VM core suspends all threads, see section <a href="#Safe_suspension">3.5.4 Safe Suspension</a>.
-         <li>
-            The VM core enumerates all the global and thread-local references in
-            the run-time data structures: the VM enumerates each frame of each
-            thread stack. <br>
-           For each frame produced by the JIT-compiled code, it
-           is necessary to enumerate the roots on that frame and to unwind to
-           the previous frame. For that, the VM calls methods
-           <code>JIT_get_root_set_from_stack_frame()</code> and
-            <code>JIT_unwind_stack_frame()</code>.
-            <ol>
-               <li>
-                  The VM identifies the method that owns the stack frame by looking
-                  up the instruction pointer value in the method code block
-                  tables.
-
-               <li>
-                  The VM passes the instruction pointer and the stack pointer
-                  registers to the JIT compiler.
-
-               <li>
-                  The JIT identifies the safe point and finds the GC map associated
-                  with the code address.
-
-               <li>
-                  The JIT consults the GC map for the safe point, and enumerates
-                  the root set for the frame. For that, the JIT calls the
-                  function <code>gc_add_root_set_entry()</code> for each stack
-                  location, which contains pointers to the Java<a href=
-                  "#*">*</a> heap [<a href="#GC_article_ref">12</a>].<br>
-                   The interpreter uses its own stack frame format and
-                  enumerates all thread stack trace when the interpreter
-                  function <code>interpreter_enumerate_thread()</code> is
-                  called.
-
-            </ol>
-
-         <li>The
-            VM core and the execution engine communicate the roots to the garbage collector
-            by calling the function
-            <code>gc_add_root_set_entry(ManagedObject)</code>.
-
-			 <p class="note">
-               Note
-            </p>
-            <p class="notetext">
-               The parameter points to the root, not to the object the root
-               points to. This enables the garbage collector to update the root
-               in case it has changed object locations during the collection.
-            </p>
-        <li>The
-            VM core returns from
-            <code>vm_enumerate_root_set_all_threads()</code>, so that the
-            garbage collector has all the roots and proceeds to collect objects
-            no longer in use, possibly moving some of the live objects.
-
-        <li>
-            The GC determines the set of reachable objects by tracing the reference
-            graph. In the graph, Java<a href="#*">*</a> objects are vertices
-            and directed edges are connectors between the objects having
-            reference pointers to other objects.
-
-        <li>
-            The GC calls the VM function <code>vm_resume_threads_after()</code>.
-            The VM core resumes all threads, so that the garbage collector can
-            proceed with the allocation request that triggered garbage
-            collection.
-
-
-      </ol>
-      <p class="backtotop">
-         <a href="#Top">Back to Top</a>
-      </p>
-      <h2>
-         <a name="Finalization"></a>2.7 Finalization
-      </h2>
-      <p>
-         <em>Finalization</em> is the process of reclaiming unused system
-         resources after garbage collection. The DRL finalization fully
-         complies with the specification [<a href="#JVM_spec_ref">1</a>]. The
-         VM core and the garbage collector cooperate inside the virtual machine
-         to enable finalizing unreachable objects.
-      </p>
-      <p class="note">
-         Note
-      </p>
-      <p class="notetext">
-         In DRL, the virtual machine tries to follow the reverse finalization
-         order, so that the object created last is the first to be finalized;
-         however, the VM does not guarantee that finalization follows this or
-         any specific order.
-      </p>
-      <h3>
-         2.7.1 Finalization Procedure
-      </h3>
-      <p>
-         As Figure 2 shows, several queues can store references to finalizable
-         objects:
-      </p>
-      <ul>
-         <li>
-            <em>GC live objects queue</em> for marked objects.
-
-         <li>
-            <em>GC buffering queue</em> for unmarked objects. This queue is
-            empty most of the time.
-
-         <li>
-            <em>VM core queue</em> for objects unreachable from the root and
-            scheduled for finalization.
-
-      </ul>
-      <p align="center">
-         <img src="images/final_queques.gif" alt="Object Queues in VM and GC">
-      </p>
-      <p class="special">
-         Figure 2. Finalization Framework
-      </p>
-      <p>
-         The garbage collector uses these queues at different stages of the GC
-         procedure to enumerate the root set and kick off finalization for
-         unreachable objects, as follows.
-      </p>
-      <p class="backtotop">
-         <a href="#Top">Back to Top</a>
-      </p>
-      <ol>
-         <li>
-            <p class="class">
-               Object Allocation
-            </p>
-            <p>
-               During <a href="#Object_Allocation">object allocation</a>, the
-               garbage collector places references to finalizable objects into
-               the live object queue, as shown in Figure 3. Functions
-               <code>gc_alloc()</code> and <code>gc_alloc_fast()</code>
-               register finalizable objects with the queue.
-            </p>
-            <p align="center">
-               <img src="images/final_alloc_all.gif" alt=
-               "Allocation functions and the live objects queue">
-            </p>
-            <p class="special">
-               Figure 3. Allocation of Finalizable Objects
-            </p>
-
-         <li>
-            <p class="class">
-               After Mark Scan
-            </p>
-            <p>
-               After marking all reachable objects, the GC moves the remaining
-               object references to the unmarked objects queue. Figure 4
-               illustrates this procedure: grey squares stand for marked object
-               references, and white square are the unmarked object references.
-            </p>
-            <p align="center">
-               <img src="images/final_unmarked_queue.gif" alt=
-               "Marked Objects moved to Queue 1 and unmarked objects to Queue 2">
-            </p>
-            <p class="special">
-               Figure 4. Unmarked Objects Queue Usage
-            </p>
-
-         <li>
-            <p class="class">
-               Filling in the Finalizable Objects Queue
-            </p>
-            <p>
-               From the buffering queue, the GC transfers unmarked object
-               references to the VM queue, as shown in Figure 5. To place a
-               reference into the queue, the garbage collector calls the
-               <code>vm_finalize_object()</code> function for each reference
-               until the unmarked objects queue is empty.
-            </p>
-            <p align="center">
-               <img src="images/final_final_queue.gif" alt=
-               "Unmarked Objects are moved to Queue 3 of finalizable objects">
-            </p>
-            <p class="special">
-               Figure 5. Finalization Scheduling
-            </p>
-
-         <li>
-            <p class="class">
-               Activating the Finalizer Thread
-            </p>
-            <p>
-               Finally, the GC calls the <code>vm_hint_finalize()</code>
-               function that wakes up finalizer threads. All finalizer threads
-               are pure Java<a href="#*">*</a> threads, see section <a href=
-               "#work_balance">2.7.2 Work Balancing Subsystem</a>.<br>
-                Each active thread takes one object to finalize and does the
-               following:
-            </p>
-            <ol>
-               <li>
-                  Gets references to the object from the VM queue
-
-               <li>
-                  Removes the reference from the queue
-
-               <li>
-                  Calls the <code>finalize()</code> function for the object
-
-            </ol>
-            <p>
-               If the number of active threads is greater than the number of
-               objects, the threads that have nothing to finalize are
-               transferred to the sleep mode, as shown in Figure 6.
-            </p>
-            <p align="center">
-               <img src="images/final_threads.gif" alt=
-               "Active finalizer threads address objects in the finalizable objects queue or sleep">
-            </p>
-            <p class="special">
-               Figure 6. Finalizer Threads
-            </p>
-
-      </ol>
-      <p class="backtotop">
-         <a href="#Top">Back to Top</a>
-      </p>
-      <h3>
-         <a name="work_balance"></a>2.7.2 Work Balancing Subsystem
-      </h3>
-      <p>
-         The work balancing subsystem dynamically adjusts the number of running
-         finalizer threads to prevent an overflow of the Java heap by
-         finalizable objects. This subsystem operates with two kinds of
-         finalizer threads: permanent and temporary. During normal operation
-         with a limited number of finalizable objects, permanent threads can
-         cover all objects scheduled for finalization. When permanent threads
-         are no longer sufficient, the work balancing subsystem activates
-         temporary finalizer threads as needed.
-      </p>
-      <p>
-         The work balancing subsystem operates in the following stages:
-      </p>
-      <dl>
-         <dt>
-            Stage 1: Permanent finalizer threads only
-         </dt>
-         <dd>
-            Object allocation starts. Only permanent finalizer threads run. The
-            garbage collector uses the hint counter variable to track
-            finalizable objects, and increases the value of the hint counter by
-            1 when allocating a finalizable object.
-         </dd>
-         <dt>
-            Stage 2: Temporary finalizer activated
-         </dt>
-         <dd>
-            The number of objects scheduled for finalization increases, and at
-            some point in time, the hint counter value exceeds a certain
-            threshold (currently set to 128). <br>
-           At this stage, the garbage collector calls the
-          <code>vm_hint_finalize()</code> function before performing the
-            requested allocation. This function is also called after each
-            garbage collection. The <code>vm_hint_finalize()</code> function
-            checks whether any objects remain in the queue of objects to
-            finalize. If the queue is not empty, this means that the current
-            quantity of finalizer threads is not enough. In this case, the work
-            balancing subsystem creates additional temporary finalizer threads.
-            The number of created temporary threads corresponds to the number of
-            CPUs.<br>
-             The operation of checking the finalizable objects queue state is performed periodically.
-			 The number of running temporary threads can be greater than
-            suffices, because the optimum number of finalizer threads is
-            unknown.
-            <p class="note">
-               Note
-            </p>
-            <p class="notetext">
-               The work balancing subsystem checks whether the finalization
-               queue is empty, but does not take into account the number of
-               objects in the queue.
-            </p>
-		</dd>
-         <dt>&nbsp;
-
-        </dt>
-         <dt>
-            Stage 3: Temporary finalizer threads destroyed
-         </dt>
-         <dd>
-            At a certain point, excess finalizer threads can appear, so that
-            the number of objects to finalize starts decreasing. When the
-            number of threads becomes two times greater than the optimal number, the
-            finalizable objects queue should be empty, see explanation
-            below.<br>
-             When the finalization queue is empty, temporary threads are
-            destroyed and the work balancing cycle restarts.
-         </dd>
-      </dl>
-      <p class="class">
-         WBS Internals
-      </p>
-      <p>
-         Assuming that N is an indefinite optimum number of finalizer threads,
-         you can make the following conclusions:
-      </p>
-      <ul>
-         <li>
-            Number N-1 finalizer threads is not enough, and all the Java<a
-            href="#*">*</a> heap gets filled with finalizable objects.
-
-         <li>
-            Number N+1 threads is an excess quantity that will cause certain
-            threads to wait.
-
-         <li>
-            N threads is the optimum solution, however, this cannot be achieved
-            if N is unknown.
-
-      </ul>
-      <p>
-         If N is less or equal to the number of permanent finalizer threads, no temporary threads are created.
-		 Otherwise, the number of finalizer threads undergoes the
-         following changes during WBS activity, in the chronological order:
-      </p>
-      <ol>
-         <li type="a">
-         When the hint counter exceeds the pre-set threshold, and the finalization queue is not empty,
-		 the work balance subsystem activates temporary threads as needed.
-
-
-         <li type="a">
-            When the number of temporary threads exceeds N, the number the
-            objects starts decreasing; however, the number of finalizer threads
-            continues to grow. By the time the number of finalizer threads
-            reaches 2N, no objects remain in the queue, because at this time an
-            optimum finalization system could finalize the same quantity of
-            objects as current.
-
-         <li type="a">
-            When the queue is empty, temporary threads are destroyed, as
-            described in stage 3.
-
-      </ol>
-      <p>
-         Figure 7 below demonstrates variations in the number of finalizer
-         threads over time.
-      </p>
-      <p align="center">
-         <img src="images/final_graph.gif" alt=
-         "Number of objects to finalize and of running threads changing dynamically">
-      </p>
-      <p class="special">
-         Figure 7. Variations in Number of Running Finalizer Threads
-      </p>
-      <p>
-         As a result, the number of running finalizer threads in the current
-         work balancing subsystem can vary between 0 and 2N.
-      </p>
-      <p class="note">
-         Note
-      </p>
-      <p class="notetext">
-         The maximum value for 2N is 256 running finalization threads.
-      </p>
-      <p class="backtotop">
-         <a href="#Top">Back to Top</a>
-      </p>
-      <h1>
-         <a name="VM_Core"></a>3. VM Core
-      </h1>
-      <h2>
-         <a name="VMCore_architecture"></a>3.1 Architecture
-      </h2>
-      <p>
-         The core virtual machine is the central part of the overall VM design.
-         The VM core consists of common VM blocks defined by the JVM
-         specification [<a href="#JVM_spec_ref">1</a>] and of elements specific
-         for the DRLVM implementation, as follows:
-      </p>
-      <ul>
-         <li>
-            <a href="#Class_support">Class support</a> encapsulates class
-            loading and resolution, as well as the functional interface to VM
-            internal class representation. This component provides interfaces
-            for class loading and accessing class structures.
-
-         <li>
-            <a href="#Kernel_Classes">Kernel classes</a> component includes a
-            subset of the Java<a href="#*">*</a> class library closely tied
-            with the virtual machine, which mostly includes classes of the
-            <code>java.lang</code> package.
-
-         <li>
-            <a href="#Kernel_Class_Natives">Kernel class native</a> methods
-            link the Java<a href="#*">*</a> kernel classes with other DRLVM
-            components, and are exported as ordinary native methods from the VM
-            executable according to the Java<a href="#*">*</a> Native Interface
-            (JNI) specification [<a href="#JNI_ref">5</a>].
-
-         <li>
-            <a href="#JNI_support">JNI support</a> component supports execution
-            of native methods for Java<a href="#*">*</a> classes, and for the
-            native interface API [<a href="#JNI_ref">5</a>].
-
-         <li>
-            <a href="#JVMTI_Support">JVMTI support</a> enables loading of the
-            debugging agent, and provides functionality for running simple
-            debug scenarios, see the JVM Tool Interface Specification [<a href=
-            "#JVMTI_ref">4</a>].
-
-         <li>
-            <a href="#Stack_Support">Stack support</a> allows stack examination
-            for creating stack traces and performing enumeration of live
-            references.
-
-         <li>
-            <a href="#Exception_Handling">Exception handling</a> is activated
-            when an exception is thrown; this component is responsible calling
-            the appropriate exception handler and, together with the stack
-            support, for the stack walking process.
-
-         <li>
-            <a href="#VM_Services">VM services</a> include run-time,
-            compilation time, and compiled code utilities provided by the VM
-            core for the JIT compiler, and utilities for the garbage collector
-            and for class library natives.
-
-         <li>
-            <a href="#Verifier">Verifier</a> checks the classes to meet safety
-            requirements before class loading.
-
-         <li>
-            <a href="#Thread_Management">Thread management</a> functionality
-            provides threading inside the virtual machine.
-
-         <li>
-            <a href="#Utilities">Utilities</a> are used by the VM core during
-            normal operation.
-
-      </ul>
-      <p>
-         The structure of the virtual machine enables building stable
-         interfaces for inter-block communication as well as public VM
-         interfaces. These interfaces inherit platform independence from the VM
-         specification [<a href="#JVM_spec_ref">1</a>]. Figure 8 shows the VM
-         core overall structure and the internal logic of components
-         interaction. For more details on available interfaces, see <a href=
-         "#VM_exported_interfaces">3.13 Interfaces</a>.
-      </p>
-      <table align="center">
-         <tr>
-            <td>
-               <img border="0" alt="VM Core Components and Interfaces" src=
-               "images/VM_core.gif">
-            </td>
-         </tr>
-         <tr>
-            <td>
-               <p class="special">
-                  <a name="Figure:VM_Core_Components"></a>Figure 8. VM Core
-                  Components
-               </p>
-               <p class="notetext">
-                  Red font indicates external interfaces.
-               </p>
-            </td>
-         </tr>
-      </table>
-      <p class="backtotop">
-         <a href="#Top">Back to Top</a>
-      </p>
-      <h2>
-         <a name="Class_support"></a>3.2 Class Support
-      </h2>
-      <p>
-         The class support component processes classes in accordance with the
-         JVM specification [<a href="#JVM_spec_ref">1</a>], which includes
-         class loading, class preparation, resolution, and initialization
-         operations. This component also contains several groups of functions
-         that other VM components use to get information on loaded classes and
-         other class-related data structures. For example, JVMTI functions
-         <code>RedefineClasses()</code> and <code>GetLoadedClasses()</code> use
-         utility interfaces provided by class support.
-      </p>
-      <p>
-         The class support component has the following major goals:
-      </p>
-      <ul>
-         <li>
-            Load binary class data from <code>.class</code> files and
-            <code>.jar</code> archives from the bootstrap class loader
-
-         <li>
-            Create internal (VM) representations of classes from byte arrays
-
-         <li>
-            Provide access to information on classes, methods, and fields for
-            various VM modules
-
-         <li>
-            Provide instruments for class redefinition and class support
-            related events required for JVMTI
-
-         <li>
-            Communicate with the verifier on verification of methods bytecode
-
-      </ul>
-      <h3>
-         3.2.1 Classification of Class Support Interfaces
-      </h3>
-      <p>
-         Class support functions can be divided into the following groups:
-      </p>
-      <dl>
-         <dt>
-            Class Loading
-         </dt>
-         <dd>
-            Comprises functions for loading classes, searching for loaded
-            classes inside VM structures, and JVMTI class redefinition. The
-            functions obtain bytes from the Java<a href="#*">*</a> class
-            libraries via the descendants of the
-            <code>java.lang.ClassLoader</code> class or from the files and
-            directories listed in the <code>vm.boot.class.path</code> property.
-            These functions also bind loaded classes with the defining class
-            loader and provide information on all loaded classes.
-         </dd>
-      </dl>
-      <dl>
-         <dt>
-            Class Manipulation
-         </dt>
-         <dd>
-            Provides access to class properties, such as the internal (VM) and
-            the external (Java<a href="#*">*</a>) names, access and properties
-            flags, the super-class and the defining class, as well as super
-            interfaces, inner classes, methods, fields, and attributes.<br>
-             Supports <i>class resolution</i> by resolving symbolic references
-            in the run-time constant pool of the class.
-         </dd>
-      </dl>
-      <dl>
-         <dt>
-            Method Manipulation
-         </dt>
-         <dd>
-            Provides access to the properties of methods of a class, such as
-            the name of method, descriptor, signature, access and properties
-            flags, bytecode, local variables information, stack, exceptions,
-            handlers, attributes, and the declaring class.<br>
-             Functions of this group also enable adding new versions of
-            JIT-compiled methods code and storing service information about
-            compiled code.
-         </dd>
-      </dl>
-      <dl>
-         <dt>
-            Field Access
-         </dt>
-         <dd>
-            Contains functions that provide access to the properties of class
-            fields, that is, to the name, descriptor, containing class, and the
-            class of the field.
-         </dd>
-      </dl>
-      <dl>
-         <dt>
-            Type Access
-         </dt>
-         <dd>
-            Provides access to generalized information on classes for the JIT
-            compiler and other DRLVM components. These can easily be adapted to
-            work with non-Java<a href="#*">*</a> virtual machines, for example,
-            with the ECMA Common Language Infrastructure. Type access functions
-            provide descriptions of both Java<a href="#*">*</a> types, such as
-            managed pointers, arrays, and primitive types, and non-Java<a href=
-            "#*">*</a> types, such as non-managed pointers, method pointers,
-            vectors, unboxed data, and certain unsigned primitive types.
-         </dd>
-      </dl>
-      <h3>
-         3.2.2 Internal Class Support Data Structures
-      </h3>
-      <p>
-         The VM core stores information about every class, field, and method
-         loaded as described below.
-      </p>
-      <ul>
-         <li>
-            <i>Class data structure</i> includes attributes of the class
-            (public, final, and abstract attributes, the element type for an
-            array class, and others), information about inner classes,
-            references to static initializers, and references to finalizers.
-            The structure also references the virtual-method table (VTable) of
-            the class shared by all instances of that class.
-
-         <li>
-            <i>Field data structure</i> includes reflection information, such
-            as name, type, and reference to the declaring class, as well as
-            internal DRLVM information, such as the fields offset from the base
-            of the object for instance fields and the fields address in memory
-            for static fields.
-
-         <li>
-            <i>Method data structure</i> contains the information on methods
-            similar to the field data structure content.
-
-      </ul>
-      <p class="backtotop">
-         <a href="#Top">Back to Top</a>
-      </p>
-      <h2>
-         <a name="Native_Code_Support"></a>3.3 Native Code Support
-      </h2>
-      <p>
-         The native code support component consists of two parts, execution of
-         native methods used by Java<a href="#*">*</a> classes, and an
-         implementation of the Java<a href="#*">*</a> Native Interface (JNI)
-         API for native code. Execution of native methods is required by the
-         Java<a href="#*">*</a> Language Specification [<a href=
-         "#Java_lang_spec_ref">2</a>] and JNI is required by JNI Specification
-         [<a href="#JNI_ref">5</a>].
-      </p>
-      <h3>
-         <a name="Execution_of_Native_Methods"></a>3.3.1 Execution of Native
-         Methods
-      </h3>
-      <p>
-         The virtual machine calls native methods differently with the JIT and
-         with the interpreter as described below.
-      </p>
-      <ul>
-         <li>
-            <i>When the JIT is used</i>, the virtual machine generates special
-            wrappers for calling native methods, which perform synchronization
-            for synchronized native methods and record information for <a href=
-            "#Stack_unwinding">stack unwinding</a> and enumeration of
-            references used in native code. The wrapper code is generated for a
-            native method when the method is called for the first time, and
-            further on, the wrapper is called from JIT-compiled code directly.
-
-      </ul>
-      <p class="class">
-         JNI optimizations
-      </p>
-      <p class="notetext">
-         The VM core generates specialized JNI wrappers to support the
-         transition from managed to native code. The straight-forward
-         implementation of these wrappers calls a function to allocate storage
-         and initialize JNI handles for each reference argument. However, most
-         JNI methods have only a small number of reference parameters. To take
-         advantage of this, an in-line sequence of instructions is used to
-         allocate and initialize the JNI handles directly. This improves the
-         performance of applications that contain multiple JNI calls.
-      </p>
-      <ul>
-         <li>
-            <i>In the interpreter mode</i>, native code is called directly with
-            static stubs, and the interpreter performs all the operations done
-            by wrappers in the JIT execution mode.
-
-      </ul>
-      <h3>
-         <a name="JNI_support"></a>3.3.2 JNI Support
-      </h3>
-      <p>
-         The Java<a href="#*">*</a> Native Interface is a set of functions,
-         which enable native code to access Java<a href="#*">*</a> classes,
-         objects, methods, and all the functionality available for a regular
-         method of a Java<a href="#*">*</a> class.
-      </p>
-      <p>
-         The JNI implementation mostly consists of wrappers to different
-         components of the virtual machine. For example, class operations are
-         wrappers for the class support component, method calls are wrappers
-         that invoke the JIT or the interpreter, and object fields and arrays
-         are accessed directly by using the known object layout.
-      </p>
-      <dl>
-         <dt>
-            Example
-         </dt>
-      </dl>
-      <p class="notetext">
-         The following code is implementation of the
-         <code>IsAssignableFrom</code> JNI function, which uses the class
-         support interface:
-      </p>
-<pre>
-#include &ldquo;vm_utils.h&rdquo;
-#include &ldquo;jni_utils.h&rdquo;
-
-jboolean JNICALL IsAssignableFrom(JNIEnv * UNREF env,
-   jclass clazz1,
-   jclass clazz2)
-{
-  TRACE2(&quot;jni&quot;, &quot;IsAssignableFrom called&quot;);
-  assert(tmn_is_suspend_enabled());
-  Class* clss1 = jclass_to_struct_Class(clazz1);
-  Class* clss2 = jclass_to_struct_Class(clazz2);
-
-  Boolean isAssignable = class_is_subtype(clss1, clss2);
-  if (isAssignable) {
- return JNI_TRUE;
-  } else {
- return JNI_FALSE;
-  }
-} //IsAssignableFrom
-</pre>
-      <p class="backtotop">
-         <a href="#Top">Back to Top</a>
-      </p>
-      <h2>
-         <a name="Stack_Support"></a>3.4 Stack Support
-      </h2>
-      <h3>
-         3.4.1 About the Stack
-      </h3>
-      <p>
-         The stack is a set of frames created to store local method
-         information. The stack is also used to transfer parameters to the
-         called method and to get back a value from this method. Each frame in
-         the stack stores information about one method. Each stack corresponds
-         to one thread.
-      </p>
-      <p class="note">
-         <a name="Note1_in_Stack_overview"></a>Note
-      </p>
-      <p class="notetext">
-         The JIT compiler can combine in-lined methods into one for performance
-         optimization. In this case, all combined methods information is stored
-         in one stack frame.
-      </p>
-      <p>
-         The VM uses native frames related to native C/C++ code and managed
-         frames for Java<a href="#*">*</a> methods compiled by the JIT.
-         Interaction between native methods is platform-specific. To transfer
-         data and control between managed and native frames, the VM uses
-         special managed-to-native frames, or <em>M2nFrames</em>.
-      </p>
-      <p class="note">
-         Note
-      </p>
-      <p class="notetext">
-         In the interpreter mode, the VM creates several native frames instead
-         of one managed frame for a Java<a href="#*">*</a> method. These native
-         frames store data for interpreter functions, which interpret the
-         Java<a href="#*">*</a> method code step by step.
-      </p>
-      <p class="class">
-         <a name="M2nFrame"></a>M2nFrames
-      </p>
-      <p>
-         M2nFrames contain the following:
-      </p>
-      <ul>
-         <li>
-            Snapshot of CPU registers, which enables iteration over method
-            frames and exception propagation. The VM uses the stack pointer and
-            the instruction pointer to identify the method and to find the
-            boundaries of the method stack frame. The VM uses values of
-            callee-saves registers to correctly restore the register context.
-            The VM performs this operation when transferring control to
-            exception handlers that are defined in the methods located lower on
-            the execution stack.
-
-         <li>
-            Pointer to the previous M2nFrame. All M2nFrames are linked into a
-            list, with the head pointer kept in thread-local structure
-            <code>VM_thread</code>. The list is terminated with a dummy frame
-            with zero contents.
-
-         <li>
-            Container of object handles that are indirect pointers to the
-            Java<a href="#*">*</a> heap. Native code must use object handles to
-            enable root set enumeration. During this process, the VM traverses
-            the list of M2nFrames for each thread and enumerates object handles
-            from each frame.
-
-      </ul>
-      <h3>
-         <a name="Stack_Walking"></a>3.4.2 Stack Walking
-      </h3>
-      <p>
-         Stack walking is the process of going from one frame on the stack to
-         another. Typically, this process is activated during exception

[... 12436 lines stripped ...]


Mime
View raw message