You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by nd...@apache.org on 2006/08/17 04:04:29 UTC
svn commit: r432111 [2/4] - in
/incubator/harmony/enhanced/drlvm/trunk/vm/doc: DeveloperGuide.htm
GettingStarted.htm conventions.htm drl.css
Modified: incubator/harmony/enhanced/drlvm/trunk/vm/doc/DeveloperGuide.htm
URL: http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/vm/doc/DeveloperGuide.htm?rev=432111&r1=432110&r2=432111&view=diff
==============================================================================
--- incubator/harmony/enhanced/drlvm/trunk/vm/doc/DeveloperGuide.htm (original)
+++ incubator/harmony/enhanced/drlvm/trunk/vm/doc/DeveloperGuide.htm Wed Aug 16 19:04:29 2006
@@ -1,7371 +1,7371 @@
-<!--
- 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.
-
- Portions, Copyright © 1991-2005 Unicode, Inc. The following applies to Unicode.
-
- COPYRIGHT AND PERMISSION NOTICE
- Copyright © 1991-2005 Unicode, Inc. All rights reserved. Distributed under the Terms of Use
- in http://www.unicode.org/copyright.html.
- Permission is hereby granted, free of charge, to any person obtaining a copy of the Unicode data files
- and any associated documentation (the "Data Files") or Unicode software and any associated documentation
- (the "Software") 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.
- THE DATA FILES AND SOFTWARE ARE PROVIDED "AS IS", 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.
- 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.
- 2. Additional terms from the Database:
- Copyright © 1995-1999 Unicode, Inc. All Rights reserved.
- Disclaimer
- 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.
- Limitations on Rights to Redistribute This Data
- 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 UnicodeTM 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.
-
--->
-<!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'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
- "License"); 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 "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.
-</p>
- <p> Portions, Copyright © 1991-2005 Unicode, Inc. The following applies to Unicode. <br>
- <br>
-COPYRIGHT AND PERMISSION NOTICE</p>
- <p> Copyright © 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 "Data Files") or Unicode software and any associated documentation
- (the "Software") 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 "AS IS", 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 © 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'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->get_class())) {
- return 0; /* Error */
- }
-
- ObjectHandle h = (ObjectHandle) obj;
-
- tmn_suspend_disable(); //-- Do not allow GC suspension --v
- Byte *java_ref = (Byte *)h->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(…)</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><vm-arguments></code> for initializing the VM instance
-
- <li>
- <code><class-name | -jar jar-file></code> for the name or
- class or <code>.jar</code> file
-
- <li>
- <code><java-arguments></code> for the user application
-
- </ul>
- <p>
- The virtual machine then creates the <code>JavaVMInitArgs</code>
- structure from <code><vm-arguments></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>–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>
-
- </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 “vm_utils.h”
-#include “jni_utils.h”
-
-jboolean JNICALL IsAssignableFrom(JNIEnv * UNREF env,
- jclass clazz1,
- jclass clazz2)
-{
- TRACE2("jni", "IsAssignableFrom called");
- 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
[... 12551 lines stripped ...]