You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by na...@apache.org on 2006/11/24 15:07:23 UTC
svn commit: r478885 [2/3] - in /harmony/standard/site:
docs/subcomponents/drlvm/ docs/subcomponents/drlvm/images/
xdocs/subcomponents/drlvm/ xdocs/subcomponents/drlvm/images/
Modified: harmony/standard/site/docs/subcomponents/drlvm/developers_guide.html
URL: http://svn.apache.org/viewvc/harmony/standard/site/docs/subcomponents/drlvm/developers_guide.html?view=diff&rev=478885&r1=478884&r2=478885
==============================================================================
--- harmony/standard/site/docs/subcomponents/drlvm/developers_guide.html (original)
+++ harmony/standard/site/docs/subcomponents/drlvm/developers_guide.html Fri Nov 24 06:07:22 2006
@@ -36,7 +36,7 @@
- <title>Apache Harmony - Developers Guide</title>
+ <title>Apache Harmony - DRLVM Developer's Guide</title>
<link rel="Stylesheet" type="text/css" href="site.css"/>
</head>
@@ -224,26 +224,27 @@
-->
-<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
-"http://www.w3.org/TR/html4/loose.dtd">
-<html>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
<head>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=windows-1252">
+ <meta http-equiv="Content-Type" content="text/html; charset=us-ascii" />
<title>
- Virtual Machine Developer's Guide
+ DRLVM Virtual Machine Developer's Guide
</title>
- <link rel="Stylesheet" type="text/css" href="site.css">
-
+ <link rel="Stylesheet" type="text/css" href="site.css" />
</head>
<body>
- <h1>
- <a id="Top" name="Top"></a>Dynamic Runtime Layer Developer's Guide</h1>
- <p class="TOCHeading"><a href="#Revision_History">Revision History</a>
- </p>
- <p class="TOCHeading">
+ <h1>
+ <a id="Top" name="Top"></a>Dynamic Runtime Layer Virtual Machine
+ Developer's Guide
+ </h1>
+ <p class="TOCHeading">
+ <a href="#Revision_History">Revision History</a>
+ </p>
+ <p class="TOCHeading">
<a href="#About_this_document">1. About this Document</a>
- </p>
+ </p>
<p class="TOC">
<a href="#Purpose">1.1 Purpose</a>
</p>
@@ -263,195 +264,217 @@
<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>
+ <a href="#About_Components">2.2 About Components</a>
</p>
+ <blockquote>
+ <p class="TOC">
+ <a href="#CompInterfInst">2.2.1 Components, Interfaces, and
+ Instances</a>
+ </p>
+ <p class="TOC">
+ <a href="#Linking_Models">2.2.2 Linking Models</a>
+ </p>
+ </blockquote>
<p class="TOC">
- <a href="#JIT_utilities">4.6 Utilities</a>
+ <a href="#Component_Manager">2.3 Component Manager</a>
</p>
<p class="TOC">
- <a href="#JIT_interfaces">4.7 Public Interfaces</a>
+ <a href="#Package_Layout">2.4 Package Layout</a>
</p>
<p class="TOC">
- <a href="#JET_introduction">4.8 Jitrino.JET</a>
+ <a href="#Data_Structures">2.5 Data Structures</a>
</p>
+ <blockquote>
+ <p class="TOC">
+ <a href="#Object_Layout">2.5.1 Object Layout</a>
+ </p>
+ <p class="TOC">
+ <a href="#Compressed_References">2.5.2 Compressed References</a>
+ </p>
+ </blockquote>
<p class="TOCHeading">
- <a href="#EM">5. Execution Manager</a>
- </p>
- <p class="TOC">
- <a href="#EM_architecture">5.1 Architecture</a>
+ <a href="#Components">3. Components</a>
</p>
<p class="TOC">
- <a href="#Recompilation">5.2 Recompilation Model</a>
+ <a href="#Major_Components">3.1 Component Structure</a>
</p>
<p class="TOC">
- <a href="#PC">5.3 Profile Collector</a>
+ <a href="#VM_Core">3.2 VM Core</a>
</p>
+ <blockquote>
+ <p class="TOC">
+ <a href="#Kernel_Classes">3.2.1 Kernel Classes</a>
+ </p>
+ <p class="TOC">
+ <a href="#Native_Code_Support">3.2.2 Native Code Support</a>
+ </p>
+ <p class="TOC">
+ <a href="#JVMTI_Support">3.2.3 JVMTI Support</a>
+ </p>
+ <p class="TOC">
+ <a href="#Class_Support">3.2.4 Class Support</a>
+ </p>
+ <p class="TOC">
+ <a href="#VM_Services">3.2.5 Services</a>
+ </p>
+ <p class="TOC">
+ <a href="#Utilities">3.2.6 Utilities</a>
+ </p>
+ </blockquote>
<p class="TOC">
- <a href="#Profiler_thread">5.4 Profiler Thread</a>
+ <a href="#EE">3.3 Execution Engine</a>
</p>
+ <blockquote>
+ <p class="TOC">
+ <a href="#JIT_Compiler">3.3.1 JIT Compiler</a>
+ </p>
+ <p class="TOC">
+ <a href="#Interpreter">3.3.2 Interpreter</a>
+ </p>
+ </blockquote>
<p class="TOC">
- <a href="#EM_interfaces">5.5 Public Interfaces</a>
- </p>
- <p class="TOCHeading">
- <a href="#GC">6. Garbage Collector</a>
+ <a href="#EM">3.4 Execution Manager</a>
</p>
<p class="TOC">
- <a href="#GC_Architecture">6.1 Architecture</a>
+ <a href="#Thread_Manager">3.5 Thread Manager</a>
</p>
<p class="TOC">
- <a href="#GC_procedure">6.2 GC Procedure</a>
+ <a href="#GC">3.6 Garbage Collector</a>
</p>
<p class="TOC">
- <a href="#Object_Allocation">6.3 Object Allocation</a>
+ <a href="#Porting_Layer">3.7 Porting Layer</a>
</p>
<p class="TOC">
- <a href="#GC_Exported_Interfaces">6.4 Public Interfaces</a>
+ <a href="#Class_Libraries">3.8 Class Libraries</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>
+ <a href="#Processes">4. Processes</a>
</p>
<p class="TOC">
- <a href="#Interpreter_structure">7.2 Internal Structure</a>
+ <a href="#Initialization">4.1 Initialization</a>
</p>
+ <blockquote>
+ <p class="TOC">
+ <a href="#1stpass">4.1.1 Parsing Arguments</a>
+ </p>
+ <p class="TOC">
+ <a href="#Creating_VM">4.1.2 Creating the VM</a>
+ </p>
+ <p class="TOC">
+ <a href="#VMStarter">4.1.3 VMStarter Class</a>
+ </p>
+ </blockquote>
<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>
+ <a href="#Verification">4.2 Verification</a>
</p>
+ <blockquote>
+ <p class="TOC">
+ <a href="#Optimized_Verification">4.2.1 Optimized Verification
+ Procedure</a>
+ </p>
+ <p class="TOC">
+ <a href="#Verifications_Classification">4.2.2 Verifications
+ Classification</a>
+ </p>
+ </blockquote>
<p class="TOC">
- <a href="#Porting_Layer_Characteristics">8.1 Characteristics</a>
+ <a href="#Stack_Walking">4.3 Stack Walking</a>
</p>
+ <blockquote>
+ <p class="TOC">
+ <a href="#About_the_Stack">4.3.1 About the Stack</a>
+ </p>
+ <p class="TOC">
+ <a href="#Stack">4.3.2 Stack Walking</a>
+ </p>
+ <p class="TOC">
+ <a href="#Stack_Iterator">4.3.3 Stack Iterator</a>
+ </p>
+ <p class="TOC">
+ <a href="#Stack_Trace">4.3.4 Stack Trace</a>
+ </p>
+ </blockquote>
<p class="TOC">
- <a href="#Component_Manager">8.2 Component Manager</a>
+ <a href="#Root_Set_Enumeration">4.4 Root Set Enumeration</a>
</p>
+ <blockquote>
+ <p class="TOC">
+ <a href="#Roots">4.4.1 About Roots</a>
+ </p>
+ <p class="TOC">
+ <a href="#Method">4.4.2 Black-box Metho</a>
+ </p>
+ <p class="TOC">
+ <a href="#Enumeration">4.4.3 Enumeration Procedure</a>
+ </p>
+ </blockquote>
<p class="TOC">
- <a href="#Portlib_exported">8.3 Public Interfaces</a>
- </p>
- <p class="TOCHeading">
- <a href="#Class_Libraries">9. Class Libraries</a>
+ <a href="#Exception_Handling">4.5 Exception Handling</a>
</p>
+ <blockquote>
+ <p class="TOC">
+ <a href="#Throwing">4.5.1 Throwing Exceptions</a>
+ </p>
+ <p class="TOC">
+ <a href="#Raising_Exceptions">4.5.2 Raising Exception</a>
+ </p>
+ <p class="TOC">
+ <a href="#Choosing">4.5.3 Choosing the Exception Handling Mode</a>
+ </p>
+ </blockquote>
<p class="TOC">
- <a href="#CL_characteristics">9.1 Characteristics</a>
+ <a href="#Finalization">4.6 Finalization</a>
</p>
+ <blockquote>
+ <p class="TOC">
+ <a href="#FP">4.6.1 Finalization Procedure</a>
+ </p>
+ <p class="TOC">
+ <a href="#Work_Balance">4.6.2 Work Balancing Subsystem</a>
+ </p>
+ </blockquote>
<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
+ <a href="#Inter_Component_Optimizations">4.7 Inter-component
Optimizations</a>
</p>
+ <blockquote>
+ <p class="TOC">
+ <a href="#Fast_Subtype_Checking">4.7.1 Fast Subtype Checking</a>
+ </p>
+ <p class="TOC">
+ <a href="#Direct_Call_Conversion">4.7.2 Direct-call Conversion</a>
+ </p>
+ <p class="TOC">
+ <a href="#Fast_Constant_String">4.7.3 Fast Constant-string
+ Instantiation</a>
+ </p>
+ <p class="TOC">
+ <a href="#Lazy_Exceptions">4.7.4 Lazy Exceptions</a>
+ </p>
+ </blockquote>
<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>
+ <a href="#Destroying_VM">4.8 Destroying the VM</a>
</p>
<p class="TOCHeading">
- <a href="#References">11. References</a>
+ <a href="#References">5. References</a>
</p>
<h1>
- <a name="Revision_History"></a>Revision History
+ <a id="Revision_History" name="Revision_History"></a>Revision History
</h1>
- <table width="100%">
+ <table>
<tr>
- <td class="TableHeading" width="25%">
+ <th class="TableHeading">
Version
- </td>
- <td class="TableHeading" width="50%">
+ </th>
+ <th class="TableHeading">
Version Information
- </td>
- <td class="TableHeading">
+ </th>
+ <th class="TableHeading">
Date
- </td>
+ </th>
</tr>
<tr>
- <td class="TableCell" width="25%">
+ <td class="TableCell">
Initial version
</td>
<td class="TableCell">
@@ -462,8 +485,8 @@
</td>
</tr>
<tr>
- <td class="TableCell" width="25%">
- Version 1.0
+ <td class="TableCell">
+ 1.0
</td>
<td class="TableCell">
Intel, Nadya Morozova: document updated and expanded.
@@ -472,27 +495,52 @@
March 2, 2006
</td>
</tr>
+ <tr>
+ <td class="TableCell">
+ 1.5
+ </td>
+ <td class="TableCell">
+ Sveta Konovalova: redundant legal notes removed.
+ </td>
+ <td class="TableCell">
+ November 22, 2006
+ </td>
+ </tr>
+ <tr>
+ <td class="TableCell">
+ 2.0
+ </td>
+ <td class="TableCell">
+ Nadya Morozova: document restructured, component implementation
+ specifics removed, VM processes described in greater detail.
+ </td>
+ <td class="TableCell">
+ November 24, 2006
+ </td>
+ </tr>
</table>
-
-
-
<h1>
- <a name="About_this_document"></a>1. About This Document
+ <a id="About_this_document" name="About_this_document"></a>1. About
+ This Document
</h1>
<h2>
- <a name="Purpose"></a>1.1 Purpose
+ <a id="Purpose" 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's
+ basic concepts and terms, and gives an overview of the product'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>
+ </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
+ <a id="Intended_Audience" name="Intended_Audience"></a>1.2 Intended
+ Audience
</h2>
<p>
The target audience for the document includes a wide community of
@@ -500,79 +548,35 @@
product to contribute to its development.
</p>
<h2>
- <a name="Using_this_document"></a>1.3 Using This Document
+ <a id="Using_This_Document" 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>
+ <ul>
+ <li>
+ <a href="#VM_Architecture">Architecture</a>: description of VM
+ internal architecture, its components and their interaction
+ principles
+ </li>
+ <li>
+ <a href="#Components">Components</a>: definitions of required VM
+ components, their role in the VM architecture
+ </li>
+ <li>
+ <a href="#Processes">Processes</a>: overview and step-by-step
+ description of key VM processes, from initialization to destruction
+ through stack walking, object finalization, and so on
+ </li>
+ </ul>
<p class="backtotop">
<a href="#Top">Back to Top</a>
</p>
<h2>
- <a name="Conventions_and_Symbols"></a>1.4 Conventions and Symbols
+ <a id="Conventions_and_Symbols" name="Conventions_and_Symbols"></a>1.4
+ Conventions and Symbols
</h2>
<p>
This document uses the <a href="conventions.htm">unified
@@ -582,14 +586,20 @@
The table below provides the definitions of all acronyms used in the
document.
</p>
- <table class="normalTable" border="0" cellpadding="0" width="100%">
+ <table class="normalTable" border="0" cellpadding="0">
<tr>
- <td class="TableHeading">
+ <th class="TableHeading">
Acronym
- </td>
- <td class="TableHeading">
+ </th>
+ <th class="TableHeading">
Definition
- </td>
+ </th>
+ <th class="TableHeading">
+ Acronym
+ </th>
+ <th class="TableHeading">
+ Definition
+ </th>
</tr>
<tr>
<td class="TableCell">
@@ -598,6 +608,12 @@
<td class="TableCell">
Application Program Interface
</td>
+ <td class="TableCell">
+ JNI
+ </td>
+ <td class="TableCell">
+ Java<a href="#*">*</a> Native Interface
+ </td>
</tr>
<tr>
<td class="TableCell">
@@ -606,6 +622,12 @@
<td class="TableCell">
Apache Portable Runtime Layer
</td>
+ <td class="TableCell">
+ JVM
+ </td>
+ <td class="TableCell">
+ Java<a href="#*">*</a> Virtual Machine
+ </td>
</tr>
<tr>
<td class="TableCell">
@@ -614,6 +636,12 @@
<td class="TableCell">
Control Flow Graph
</td>
+ <td class="TableCell">
+ JVMTI
+ </td>
+ <td class="TableCell">
+ JVM Tool Interface
+ </td>
</tr>
<tr>
<td class="TableCell">
@@ -622,6 +650,12 @@
<td class="TableCell">
Code Generator
</td>
+ <td class="TableCell">
+ LIR
+ </td>
+ <td class="TableCell">
+ Low-level Intermediate Representation
+ </td>
</tr>
<tr>
<td class="TableCell">
@@ -630,6 +664,12 @@
<td class="TableCell">
Common Language Interface
</td>
+ <td class="TableCell">
+ LMF
+ </td>
+ <td class="TableCell">
+ Last Managed Frame
+ </td>
</tr>
<tr>
<td class="TableCell">
@@ -638,14 +678,26 @@
<td class="TableCell">
Data Flow Graph
</td>
+ <td class="TableCell">
+ LOB
+ </td>
+ <td class="TableCell">
+ Large Object Block
+ </td>
</tr>
<tr>
- <td class="TableCell" height="40">
+ <td class="TableCell">
DPGO
</td>
- <td class="TableCell" height="40">
+ <td class="TableCell">
Dynamic Profile-guided Optimizations
</td>
+ <td class="TableCell">
+ LOS
+ </td>
+ <td class="TableCell">
+ Large Object Space
+ </td>
</tr>
<tr>
<td class="TableCell">
@@ -654,6 +706,12 @@
<td class="TableCell">
Dynamic Run-time Layer
</td>
+ <td class="TableCell">
+ OS
+ </td>
+ <td class="TableCell">
+ Operating System
+ </td>
</tr>
<tr>
<td class="TableCell">
@@ -662,6 +720,12 @@
<td class="TableCell">
Dynamic Run-time Layer Virtual Machine
</td>
+ <td class="TableCell">
+ PC
+ </td>
+ <td class="TableCell">
+ Profile Collector
+ </td>
</tr>
<tr>
<td class="TableCell">
@@ -670,6 +734,12 @@
<td class="TableCell">
Execution Engine
</td>
+ <td class="TableCell">
+ SIMD
+ </td>
+ <td class="TableCell">
+ Single Instruction Multiple Data
+ </td>
</tr>
<tr>
<td class="TableCell">
@@ -678,6 +748,12 @@
<td class="TableCell">
Execution Manager
</td>
+ <td class="TableCell">
+ SOB
+ </td>
+ <td class="TableCell">
+ Single Object Block
+ </td>
</tr>
<tr>
<td class="TableCell">
@@ -686,192 +762,90 @@
<td class="TableCell">
Floating Point
</td>
- </tr>
- <tr>
<td class="TableCell">
- GC
+ SSA
</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
+ Single Static Assignment
</td>
</tr>
<tr>
<td class="TableCell">
- LOS
+ GC
</td>
<td class="TableCell">
- Large Object Space
+ Garbage Collector
</td>
- </tr>
- <tr>
<td class="TableCell">
- OS
+ SSE, SSE2
</td>
<td class="TableCell">
- Operating System
+ Streaming SIMD Extensions (2)
</td>
</tr>
<tr>
<td class="TableCell">
- PC
+ HIR
</td>
<td class="TableCell">
- Profile Collector
+ High-level Intermediate Representation
</td>
- </tr>
- <tr>
<td class="TableCell">
- SIMD
+ STL
</td>
<td class="TableCell">
- Single Instruction Multiple Data
+ Standard Template Library
</td>
</tr>
<tr>
<td class="TableCell">
- SOB
+ IR
</td>
<td class="TableCell">
- Single Object Block
+ Intermediate Representation
</td>
- </tr>
- <tr>
<td class="TableCell">
- SSA
+ TBS
</td>
<td class="TableCell">
- Single Static Assignment
+ Time-based Sampling
</td>
</tr>
<tr>
<td class="TableCell">
- SSE, SSE2
+ J2SE<a href="#*">*</a>
</td>
<td class="TableCell">
- Streaming SIMD Extensions (2)
+ Java<a href="#*">*</a> 2 Standard Edition
</td>
- </tr>
- <tr>
<td class="TableCell">
- STL
+ TLS
</td>
<td class="TableCell">
- Standard Template Library
+ Thread Local Storage
</td>
</tr>
<tr>
<td class="TableCell">
- TBS
+ JCL
</td>
<td class="TableCell">
- Time-based Sampling
+ Java<a href="#*">*</a> Class Libraries
</td>
- </tr>
- <tr>
<td class="TableCell">
- TLS
+ TM
</td>
<td class="TableCell">
- Thread Local Storage
+ Thread Manager
</td>
</tr>
<tr>
<td class="TableCell">
- TM
+ JIT
</td>
<td class="TableCell">
- Thread Manager
+ Just-in-time Compiler
</td>
- </tr>
- <tr>
<td class="TableCell">
VM
</td>
@@ -884,20 +858,20 @@
<a href="#Top">Back to Top</a>
</p>
<h1>
- <a name="VM_Architecture"></a>2. VM Architecture
+ <a id="VM_Architecture" name="VM_Architecture"></a>2. VM Architecture
</h1>
<h2>
- <a name="Overview"></a>2.1 Overview
+ <a id="Overview" 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.
+ 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:
@@ -905,63 +879,66 @@
<ul>
<li>
<i>Modularity</i>: Functionality is grouped into a limited number
- of coarse-grained modules with well defined interfaces.
-
+ of coarse-grained modules with well-defined interfaces.
+ </li>
<li>
<i>Pluggability</i>: Module implementations can be replaced at
compile time or run time. Multiple implementations of a given
module are possible.
-
+ </li>
<li>
<i>Consistency</i>: Interfaces are consistent across platforms.
-
+ </li>
<li>
<i>Performance</i>: Interfaces fully enable implementation of
modules optimized for specific target platforms.
-
+ </li>
</ul>
<h2>
- <a name="Component_Structure"></a>2.2 About Components
+ <a id="About_Components" name="About_Components"></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.
+ The DRL virtual machine reconciles high performance with extensive use
+ of well-defined interfaces between its components.
</p>
- <h3><a name="CompInterfInst"></a>
- 2.2.1 Components, Interfaces, and Instances
+ <h3>
+ <a id="CompInterfInst" 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>.
+ A <em>component</em> corresponds to one static or dynamic library, so
+ that 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.
+ <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.
+ 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
+ DRL can also operate with co-existing component instances, as the
+ Invocation API [<a href="#Invoc_api_ref">7</a>] requires. 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.
+ interface and component-specific data. The <a
+ href="#Porting_Layer">porting layer</a> always has exactly one
+ instance. This allows a compiler to inline calls to the porting layer
+ functions. Other components have the same number of instances as the
+ VM core does.
</p>
<p class="class">
Background
@@ -974,20 +951,20 @@
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>
+ 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.
+ 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
+ <a id="linking_Models" name="linking_Models"></a>2.2.2 Linking Models
</h3>
<p>
Libraries corresponding to different DRL components are linked by one
@@ -998,110 +975,55 @@
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
+ components; see section <a href="#Component_Manager">2.3 Component
Manager</a>.
-
+ </li>
<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>
<li>
- Third-party components shipped as dynamic libraries, such as the
- <a href="#Memory_Management">memory manager</a>, are also loaded at run time.
-
+ Third-party components shipped as dynamic libraries, such as the <a
+ href="#Memory_Management">memory manager</a>, are also loaded at
+ run time.
+ </li>
</ul>
<p class="backtotop">
<a href="#Top">Back to Top</a>
</p>
<h2>
- <a name="major_components"></a>2.3 Major DRL Components
+ <a id="Component_Manager" name="Component_Manager"></a>2.3 Component
+ Manager
</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
+ The <em>component manager</em> is a subcomponent of the VM core
+ responsible for loading and subsequent initialization of VM
+ 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:
+ During the loading stage, the component manager queries the default
+ interface from each loading component, and then makes this information
+ available at the initialization stage via interface queries. The
+ component manager also enables instance creation for interfaces.
+ Currently, only the execution manager uses the component manager
+ loading scheme.
</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>
+ <h2>
+ <a id="Package_Layout" name="Package_Layout"></a>2.4. Package Layout
+ </h2>
<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>
+ The general distribution of source code in the package is to have a
+ directory for each major component, such as <code>jitrino/</code> for
+ the just-in-time compiler and <code>port/</code> for porting
+ functionality. For a comprehensive list of the current DRLVM package
+ layout, consult the README file in the root directory of the source
+ package.
</p>
<h2>
- <a name="Data_Structures"></a>2.4 Data Structures
+ <a id="Data_Structures" name="Data_Structures"></a>2.5 Data Structures
</h2>
<p>
This section provides an overview of data structures in DRLVM, typical
@@ -1113,12 +1035,14 @@
</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.
+ <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>
<li>
<i>Public</i> data structures shared across different DRLVM
components as listed in this section.
-
+ </li>
</ul>
<p>
For example, when compiling an access operation to an instance field,
@@ -1128,17 +1052,18 @@
representation of a class object.
</p>
<h3>
- <a name="object_layout"></a>2.4.1 Object Layout
+ <a id="Object_Layout" name="Object_Layout"></a>2.5.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.
+ 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<a href="#*">*</a> Native Interface does not specify the structure
+ of <code>jobject</code>, but DRLVM defines it internally as
+ illustrated below.
</p>
- <pre>
+<pre>
typedef struct ManagedObject {
VTable *vt;
uint32 obj_info;
@@ -1153,42 +1078,39 @@
<ul>
<li>
The <code>vt</code> field points to the object virtual-method
- table.
+ 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.
+ <a id="vtable" 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 an instance.
</p>
-
+ </li>
<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.
-
+ </li>
</ul>
<p>
- Class-specific instance fields immediately follow the <code>vt</code>
- and <code>obj_info</code> fields. Representation of array instances is
+ Class-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>
+ <p class="example">
+ Example
+ </p>
+ <p class="exampletext">
+ The excerpt of code below illustrates the usage of an object structure
+ in DRLVM for the <code>GetBooleanField()</code> JNI function.
+ </p>
+<pre class="exampletext">
typedef jobject ObjectHandle;
jboolean JNICALL GetBooleanField(JNIEnv *env,
@@ -1212,18 +1134,19 @@
} // GetBooleanField
</pre>
<h3>
- <a name="compressed_references"></a>2.4.2 Compressed References
+ <a id="Compressed_References" name="Compressed_References"></a>2.5.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.
+ To decrease memory footprint on 64-bit platforms [<a
+ href="#compres_ref">11</a>], direct object and VTable pointers are
+ compressed in an object 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
+ a direct pointer to an object VTable consists of the compressed value
+ stored in the first 32 bits of the object and of 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.
@@ -1236,5976 +1159,2290 @@
<p class="backtotop">
<a href="#Top">Back to Top</a>
</p>
+ <h1>
+ <a id="Components" name="Components"></a>3. Components
+ </h1>
+ <p>
+ This part of the guide defines required virtual machine components and
+ gives an overview of their interaction.
+ </p>
<h2>
- <a name="Initialization"></a>2.5 Initialization
+ <a id="Major_Components" name="Major_Components"></a>3.1 Component
+ Structure
</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.
+ Figure 1 below displays the major DRL components and their interfaces.
</p>
- <p>
- The <code>main(…)</code> function is responsible for the major
- stages of initialization sequence and does the following:
+ <p style="text-align: center">
+ <img src="images/DRL_structure.gif" alt="Major DRL Components"
+ width="578" height="542" border="0" />
+ </p>
+ <p class="special">
+ <a id="FigureDRLComponents" name="FigureDRLComponents"></a>Figure 1.
+ Major DRL Components
</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.
+ Figure 1 demonstrates the Java<a href="#*">*</a> run-time environment
+ (JRE) that consists of the <a href="#Class_Libraries">Java* class
+ libraries</a> (JCL) constituting the application programming interface
+ (API) and the Java<a href="#*">*</a> virtual machine with a number of
+ subcomponents listed below. In Figure 1, each component has a
+ different color. Interfaces exported by a component and calls that
+ this component does to interfaces of other components are marked with
+ the component color. Rectangles are used to show what supplementary
+ terms designate.
</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:
+ Currently, the DRL virtual machine consists of the following
+ components:
</p>
<ul>
<li>
- <code><vm-arguments></code> for initializing the VM instance
-
+ The <a href="#VM_Core">VM core</a> with its subcomponents
+ concentrates most of the JVM control functions.
+ </li>
<li>
- <code><class-name | -jar jar-file></code> for the name or
- class or <code>.jar</code> file
-
+ The <a href="#EE">execution engine</a> 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">just-in-time compiler</a> for
+ compilation and execution of method code
+ </li>
+ <li>
+ The <a href="#Interpreter">interpreter</a> for easier
+ debugging
+ </li>
+ </ul>
+ </li>
<li>
- <code><java-arguments></code> for the user application
-
+ The <a href="#EM">execution manager</a> selects the execution
+ engine for compiling a method, handles profiles and the dynamic
+ recompilation logic.
+ </li>
+ <li>
+ The <a href="#GC">garbage collector</a> allocates Java<a
+ href="#*">*</a> objects in the heap memory and reclaims unreachable
+ objects using various algorithms, for example, <code>gc_gen</code>
+ is a generational garbage collection and <code>gc_v4</code> uses
+ the mark-compact garbage collection algorithm.
+ </li>
+ <li>
+ The <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>].
+ </li>
</ul>
<p>
- The virtual machine then creates the <code>JavaVMInitArgs</code>
- structure from <code><vm-arguments></code>.
+ 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 compile time and code quality. You can aslo plug in
+ your custom components instead of the ones DRLVM includes by default,
+ provided that your components exports the required interface
+ functions. For an example of plugging in a custom garbage collector,
+ see <a href="gc-howto.html">How to Write DRL GC</a>.
</p>
- <h3><a name="creating_vm"></a>
- 2.5.2 Creating the VM
- </h3>
+ <p class="backtotop">
+ <a href="#Top">Back to Top</a>
+ </p>
+ <h2>
+ <a id="VM_Core" name="VM_Core"></a>3.2 VM Core
+ </h2>
<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:
+ 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>
- <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>–Xbootclasspath</code>
- command-line options to change the settings.
-
- <li>
- Initializes system signal handlers.
-
+ <ul>
<li>
- Parses VM arguments.
-
+ The <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. Kernel class native methods are exported
+ as ordinary native methods from the VM executable to link the
+ Java<a href="#*">*</a> kernel classes with other DRLVM components
+ and for <a href="#Class_Libraries">class library</a> purposes.
+ </li>
<li>
- Initializes JIT compiler instances.
-
+ The <a href="#JNI_support">JNI support</a> component supports
+ execution of native methods for Java<a href="#*">*</a> classes
+ implements the Java<a href="#*">*</a> native interface API [<a
+ href="#JNI_ref">5</a>].
+ </li>
<li>
- Initializes the VM memory allocator.
-
+ The <a href="#JVMTI_Support">JVMTI support</a> component enables
+ loading of the debugging agent, and provides functionality for
+ running debug scenarios, see the JVM Tool Interface Specification
+ [<a href="#JVMTI_ref">4</a>].
+ </li>
<li>
- Initializes the garbage collector by calling <a href=
- "#gc_init"><code>gc_init()</code></a>.
-
+ <a href="#Class_Support">Class support</a> is responsible for class
+ loading and related procedures.
+ </li>
<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>
-
+ <a href="#VM_Services">VM services</a> is an abstract term that
+ denotes run-time and compile-time utilities provided by the VM core
+ for the JIT compiler, the garbage collector and the class library
+ natives.
+ </li>
<li>
- Initializes the JNI support VM core component.
-
+ <a href="#Utilities">Utilities</a> are a set of functions used by
+ the VM core during normal operation.
+ </li>
<li>
- Initializes the JVMTI support functionality, loads agent dynamic
- libraries. At this step, the <em>primordial phase</em> starts.
-
+ The verifier component responsible for <a
+ href="#Verification">verification</a> procedures.
+ </li>
<li>
- Attaches the current thread and creates the <a href=
- "#M2nFrame">M2nFrame</a> at the top of the stack (step 2).
-
+ Exception handling code works to <a
+ href="#Exception_Handling">catch exceptions</a>.
+ </li>
<li>
- Initializes the bootstrap class loader.
-
+ Stack support is involved in <a href="#Stack_Walking">stack
+ walking</a> operations.
+ </li>
+ </ul>
+ <p>
+ The VM core interacts with the following DRL components:
+ </p>
+ <ul>
<li>
- Preloads the classes required for further VM operation.
-
+ The <a href="#JIT_Compiler">just-in-time compiler</a> to compile
+ Java<a href="#*">*</a> code into native code and then execute it
+ </li>
<li>
- Caches the class handles for the core classes into the VM
- environment.
-
+ The <a href="#Interpreter">interpreter</a> to execute Java<a
+ href="#*">*</a> code
+ </li>
<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>
-
+ The <a href="#GC">garbage collector</a> to allocate and free memory
+ inside the virtual machine and to enumerate the root set when
+ needed
+ </li>
<li>
- Sends the <code>VMStart</code> JVMTI event. This step begins the
- <em>start phase</em>.
-
+ The <a href="#EM">execution manager</a> to select the execution
+ engine for Java<a href="#*">*</a> code
+ </li>
<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.
-
+ The <a href="#Class_Libraries">Java* class libraries</a> to
+ interact with the user Java<a href="#*">*</a> code
+ </li>
<li>
- Calls the <a href=
- "#vmstarterinit"><code>VMStarter.initialize()</code></a> method.
-
- </ol>
+ The <a href="#Thread_Manager">thread manager</a> to handle
+ threading
+ </li>
+ </ul>
+ <p class="backtotop">
+ <a href="#Top">Back to Top</a>
+ </p>
<h3>
- <a name="destroying_vm"></a>2.5.3 Destroying the VM
+ <a id="Kernel_Classes" name="Kernel_Classes"></a>3.2.1 Kernel classes
</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.
+ The VM kernel classes link the virtual machine with the Java<a
+ href="#*">*</a> class libraries (JCL), and consist of the Java<a
+ href="#*">*</a> part and the native part. Examples of kernel classes
+ include <code>java.lang.Object</code> and
+ <code>java.lang.reflect.Field</code>. For details on the current
+ implementation, see the <a href="kernel_classes.html">Kernel Classes
+ document</a>.
</p>
- <h3><a name="VMStarter"></a>
- 2.5.4 VMStarter class
+ <p class="backtotop">
+ <a href="#Top">Back to Top</a>
+ </p>
+ <h3>
+ <a id="Native_Code_Support" name="Native_Code_Support"></a>3.2.2
+ Native Code Support
</h3>
<p>
- This Java<a href="#*">*</a> class supports specific VM core tasks by
- providing the following methods:
+ 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 defined by the
+ Java<a href="#*">*</a> Language specification [<a
+ href="#Java_lang_spec_ref">2</a>] and JNI is defined by the JNI
+ specification [<a href="#JNI_ref">5</a>].
</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()
+ <a id="Execution_of_Native_Methods"
+ name="Execution_of_Native_Methods"></a>Execution of Native Methods
</dt>
<dd>
- Called by the <code>destroy_vm()</code> method, does the following:
-
+ <p>
+ The virtual machine calls native methods differently with the
+ JIT and with the interpreter as described below.
+ </p>
<ul>
<li>
- Waits for non-daemon threads
-
- <li>
- Calls the <code>System.exit()</code> method
-
+ <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.
+ </li>
+ <li>
+ <i>In the JIT mode</i>, the virtual machine generates special
+ wrappers for calling native methods, which perform
+ synchronization for synchronized native methods and record
+ information for stack unwinding 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.<br />
+ For optimization purposes, the current implementation uses
+ an inline sequence of instructions to allocate and initialize
+ JNI handles directly. This improves performance of
+ applications that contain multiple JNI calls.
+ </li>
</ul>
</dd>
<dt>
- <a name="vmstarterstart"></a>start()
+ <a id="JNI_support" name="JNI_support"></a>JNI Support
</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
+ <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>
+ <p class="example">
+ Example
+ </p>
+ <p class="exampletext">
+ The following code is implementation of the
+ <code>IsAssignableFrom</code> JNI function, which uses the class
+ support interface:
+ </p>
+<pre class="exampletext">
+#include “vm_utils.h”
+#include “jni_utils.h”
- <li>
- Starts the thread that invokes the <code>main()</code> method
- and caches exceptions from this method
+jboolean JNICALL IsAssignableFrom(JNIEnv * UNREF env,
+ jclass clazz1,
+ jclass clazz2)
+{
+ TRACE2("jni", "IsAssignableFrom called");
+ assert(hythread_is_suspend_enabled());
+ Class* clss1 = jclass_to_struct_Class(clazz1);
+ Class* clss2 = jclass_to_struct_Class(clazz2);
- </ul>
+ Boolean isAssignable = class_is_subtype(clss1, clss2);
+ if (isAssignable) {
+ return JNI_TRUE;
+ } else {
+ return JNI_FALSE;
+ }
+} //IsAssignableFrom
+</pre>
+ <p class="exampletext">
+ This code fragment shows a wrapper to the <a
+ href="#Class_Support">class loader</a> internal function
+ <code>class_is_subtype()</code>, which checks whether a class
+ extends another class. This function works with internal class
+ loader type <code>Class</code>, which is an internal
+ representation of the loaded class instance. To obtain a pointer
+ to the <code>Class</code> instance, the code uses
+ <code>jclass_to_struct_Class()</code> class loader interface
+ functions. <code>TRACE2</code> is a call to <a href="#Logger">VM
+ logging facilities</a>.
+ </p>
</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
+ <a id="JVMTI_Support" name="JVMTI_Support"></a>3.2.3 JVMTI Support
</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.
+ In DRLVM, the JVMTI support component implements the standard JVMTI
+ interface responsible for debugging and profiling.
</p>
<p>
- Roots consist of:
+ The DRLVM implementation of JVMTI mostly consists of wrapper
+ functions, which request service and information from other VM parts,
+ such as the class loader, the JIT, the interpreter, and the thread
+ management functionality. Another part of JVMTI implementation is
+ written for service purposes, and comprises agent loading and
+ registration, events management, and API extensions support.
+ </p>
+ <p>
+ The JVMTI support component is responsible for the following groups of
+ operations:
</p>
<ul>
<li>
- Global references, such as static fields of classes, JNI global handles,
- interned string references
+ <i>Debugging</i>: control of threads and thread groups, stack
+ inspection, local variables access, access to information on
+ objects and classes, fields and methods, support of breakpoints,
+ and JNI function calls interception
+ </li>
<li>
- Thread-specific references in managed stack frames, local JNI
- handles, and the per-thread data structures maintained by the VM
- core
-
+ <i>Profiling</i>: classes redefinition for Java<a href="#*">*</a>
+ bytecode instrumentation
+ </li>
+ <li>
+ <i>General</i>: getting VM capabilities, registering event
+ callbacks, requesting supported API extensions, and other
+ operations
+ </li>
</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 class="note">
+ Note
+ </p>
+ <p class="notetext">
+ The debugging and profiling functionality of the JVMTI support
+ component rely on support from <a href="#EE">execution engines</a>.
</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.
+ See tutorial <i>Creating a Debugging and Profiling Agent with
+ JVMTI</i> [<a href="#debug_tut_ref">8</a>] for examples of JVMTI API
+ usage.
</p>
<p class="backtotop">
<a href="#Top">Back to Top</a>
</p>
<h3>
- 2.6.3 Enumeration Procedure
+ <a id="Class_Support" name="Class_Support"></a>3.2.4 Class Support
</h3>
<p>
- When the GC decides to do garbage collection, it enumerates all roots
- as described below.
+ In DRLVM, the class loading process goes in accordance with the JVM
+ specification [<a href="#JVM_spec_ref">1</a>] and includes class
+ loading, class preparation, resolution, and initialization operations.
+ The VM interface responsible for class support 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>
- <ol>
+ <p>
+ The class support component has the following major goals:
+ </p>
+ <ul>
<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>.
+ Load binary class data from <code>.class</code> files and
+ <code>.jar</code> archives from the bootstrap class loader
+ </li>
<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>
+ Create internal (VM) representations of classes from byte arrays
+ </li>
<li>
- <em>GC live objects queue</em> for marked objects.
-
+ Provide access to information on classes, methods, and fields for
+ various VM modules
+ </li>
<li>
- <em>GC buffering queue</em> for unmarked objects. This queue is
- empty most of the time.
-
+ Provide instruments for class redefinition and class support
+ related events required for JVMTI
+ </li>
<li>
- <em>VM core queue</em> for objects unreachable from the root and
- scheduled for finalization.
-
+ Communicate with the verifier on verification of methods bytecode
+ </li>
</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 class="class">
+ <a id="Classification" name="Classification"></a>Classification of
+ Class Support Interfaces
</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>
+ Class support functions can be divided into the following groups:
</p>
- <ol>
- <li>
- <p class="class">
- Object Allocation
- </p>
+ <dl>
+ <dt>
+ <a id="Class_Loading" name="Class_Loading"></a>Class Loading
+ </dt>
+ <dd>
<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
+ 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.
</p>
+ </dd>
+ <dt>
+ <a id="Class_Manipulation" name="Class_Manipulation"></a>Class
+ Manipulation
+ </dt>
+ <dd>
<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
+ 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.
</p>
+ </dd>
+ <dt>
+ <a id="Method_Manipulation" name="Method_Manipulation"></a>Method
+ Manipulation
+ </dt>
+ <dd>
<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.
+ Provides access to the properties of methods of a class, such as
+ the name of the 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.
</p>
- <p align="center">
- <img src="images/final_final_queue.gif" alt=
- "Unmarked Objects are moved to Queue 3 of finalizable objects">
+ </dd>
+ <dt>
+ <a id="Field_Access" name="Field_Access"></a>Field Access
+ </dt>
[... 7283 lines stripped ...]