You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by ge...@apache.org on 2006/08/05 20:22:39 UTC
svn commit: r429024 [2/3] - in
/incubator/harmony/standard/site/xdocs/subcomponents/drlvm:
DeveloperGuide.htm GettingStarted.htm developers_guide.xml
getting_started.xml
Added: incubator/harmony/standard/site/xdocs/subcomponents/drlvm/DeveloperGuide.htm
URL: http://svn.apache.org/viewvc/incubator/harmony/standard/site/xdocs/subcomponents/drlvm/DeveloperGuide.htm?rev=429024&view=auto
==============================================================================
--- incubator/harmony/standard/site/xdocs/subcomponents/drlvm/DeveloperGuide.htm (added)
+++ incubator/harmony/standard/site/xdocs/subcomponents/drlvm/DeveloperGuide.htm Sat Aug 5 11:22:38 2006
@@ -0,0 +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
[... 5180 lines stripped ...]