Return-Path: Delivered-To: apmail-incubator-harmony-commits-archive@www.apache.org Received: (qmail 17837 invoked from network); 5 Aug 2006 18:46:06 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 5 Aug 2006 18:46:06 -0000 Received: (qmail 89076 invoked by uid 500); 5 Aug 2006 18:46:05 -0000 Delivered-To: apmail-incubator-harmony-commits-archive@incubator.apache.org Received: (qmail 89034 invoked by uid 500); 5 Aug 2006 18:46:05 -0000 Mailing-List: contact harmony-commits-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: harmony-dev@incubator.apache.org Delivered-To: mailing list harmony-commits@incubator.apache.org Received: (qmail 88943 invoked by uid 99); 5 Aug 2006 18:46:04 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 05 Aug 2006 11:46:04 -0700 X-ASF-Spam-Status: No, hits=-9.4 required=10.0 tests=ALL_TRUSTED,NO_REAL_NAME X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [140.211.166.113] (HELO eris.apache.org) (140.211.166.113) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 05 Aug 2006 11:46:01 -0700 Received: by eris.apache.org (Postfix, from userid 65534) id D68AB1A981D; Sat, 5 Aug 2006 11:45:40 -0700 (PDT) Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: svn commit: r429028 [2/3] - in /incubator/harmony/standard/site/xdocs/subcomponents/drlvm: DeveloperGuide.htm GettingStarted.htm index.xml Date: Sat, 05 Aug 2006 18:45:39 -0000 To: harmony-commits@incubator.apache.org From: geirm@apache.org X-Mailer: svnmailer-1.0.8 Message-Id: <20060805184540.D68AB1A981D@eris.apache.org> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Modified: 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=429028&r1=429027&r2=429028&view=diff ============================================================================== --- incubator/harmony/standard/site/xdocs/subcomponents/drlvm/DeveloperGuide.htm (original) +++ incubator/harmony/standard/site/xdocs/subcomponents/drlvm/DeveloperGuide.htm Sat Aug 5 11:45:39 2006 @@ -1,7371 +1,7332 @@ - - - - - - - Virtual Machine Developer's Guide - - - - - -

- Dynamic Runtime Layer Developer's Guide -

Revision History -

-

Disclaimer -

-

- 1. About this Document -

-

- 1.1 Purpose -

-

- 1.2 Intended Audience -

-

- 1.3 Using This Document -

-

- 1.4 Conventions and Symbols -

-

- 2. VM Architecture -

-

- 2.1 Overview -

-

- 2.2 About Components -

-

- 2.3 Major DRL Components -

-

- 2.4 Data Structures -

-

- 2.5 Initialization -

-

- 2.6 Root Set Enumeration -

-

- 2.7 Finalization -

-

- 3. VM Core -

-

- 3.1 Architecture -

-

- 3.2 Class Support -

-

- 3.3 Native Code Support -

-

- 3.4 Stack Support -

-

- 3.5 Thread Management -

-

- 3.6 Kernel Classes -

-

- 3.7 Kernel Class Natives -

-

- 3.8 VM Services -

-

- 3.9 Exception Handling -

-

- 3.10 JVMTI Support -

-

- 3.11 Verifier -

-

- 3.12 Utilities -

-

- 3.13 Public Interfaces -

-

- 4. JIT Compiler -

-

- 4.1 Architecture -

-

- 4.2 Front-end -

-

- 4.3 Optimizer -

-

- 4.4 Code Selector -

-

- 4.5 IA-32 Back-end -

-

- 4.6 Utilities -

-

- 4.7 Public Interfaces -

-

- 4.8 Jitrino.JET -

-

- 5. Execution Manager -

-

- 5.1 Architecture -

-

- 5.2 Recompilation Model -

-

- 5.3 Profile Collector -

-

- 5.4 Profiler Thread -

-

- 5.5 Public Interfaces -

-

- 6. Garbage Collector -

-

- 6.1 Architecture -

-

- 6.2 GC Procedure -

-

- 6.3 Object Allocation -

-

- 6.4 Public Interfaces -

-

- 7. Interpreter -

-

- 7.1 Characteristics -

-

- 7.2 Internal Structure -

-

- 7.3 Support Functions -

-

- 8. Porting Layer -

-

- 8.1 Characteristics -

-

- 8.2 Component Manager -

-

- 8.3 Public Interfaces -

-

- 9. Class Libraries -

-

- 9.1 Characteristics -

-

- 9.2 Packaging Structure -

-

- 10. Inter-component - Optimizations -

-

- 10.1 Fast Subtype Checking -

-

- 10.2 Direct-call Conversion -

-

- 10.3 Fast Constant-string - Instantiation -

-

- 10.4 Lazy Exceptions -

-

- 11. References -

-

- Revision History -

- - - - - - - - - - - - - - - - -
- Version - - Version Information - - Date -
- Initial version - - Intel, Nadya Morozova: document created. - - November 16, 2005 -
- Version 1.0 - - Intel, Nadya Morozova: document updated and expanded. - - March 2, 2006 -
-

- Disclaimer and Legal Information -

-

- 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.

-

- 1. About This Document -

-

- 1.1 Purpose -

-

- 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. -

-

The document describes version 1 of the DRL virtual machine donated in March 2006.

-

- 1.2 Intended Audience -

-

- 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. -

-

- 1.3 Using This Document -

-

- This document consists of several major parts describing the key - processes and components of the DRL virtual machine, as follows: -

-

- Part 2. VM Architecture provides an - overview of the DRL component-based model and describes the major - inter-component processes running inside the virtual machine, such as - root set enumeration and object finalization. The part also comprises a - section about data structures used in - DRLVM. You can start with this part to learn about major principles of - VM internal operation. -

-

- Part 3. VM Core gives an in-depth description - of the core virtual machine and its subcomponents responsible for - various functions of the virtual machine, including stack walking and thread management. -

-

- Part 4. JIT Compiler 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. -

-

- Part 5. Execution Manager shows the details of the - dynamic profile-guided optimization subsystem. In this part, you can - find information on method profiles and recompilation logic. -

-

- Part 6. Garbage Collector 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. -

-

- Part 7. Interpreter has a description of - the interpreter component and its debugging services. -

-

- Part 8. Porting Layer gives an overview - of platform-dependent functionality used in DRL. The part also - includes an overview of the component - manager. -

-

- Part 9. Class Libraries gives - information on the layout and characteristics of the Java* class libraries interacting with the DRL virtual machine. -

-

- Part 10. Inter-component - Optimizations is devoted to performance-improving operations that - involve multiple components. -

-

- Part 11. References 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. -

-

- Back to Top -

-

- 1.4 Conventions and Symbols -

-

- This document uses the unified - conventions for the DRL documentation kit. -

-

- The table below provides the definitions of all acronyms used in the - document. -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Acronym - - Definition -
- API - - Application Program Interface -
- APR - - Apache Portable Runtime Layer -
- CFG - - Control Flow Graph -
- CG - - Code Generator -
- CLI - - Common Language Interface -
- DFG - - Data Flow Graph -
- DPGO - - Dynamic Profile-guided Optimizations -
- DRL - - Dynamic Run-time Layer -
- DRLVM - - Dynamic Run-time Layer Virtual Machine -
- EE - - Execution Engine -
- EM - - Execution Manager -
- FP - - Floating Point -
- GC - - Garbage Collector -
- HIR - - High-level Intermediate Representation -
- IR - - Intermediate Representation -
- J2SE* - - Java* 2 Standard Edition -
- JCL - - Java* Class Libraries -
- JIT - - Just-in-time Compiler -
- JNI - - Java* Native Interface -
- JVM - - Java* Virtual Machine -
- JVMTI - - JVM Tool Interface -
- LIR - - Low-level Intermediate Representation -
- LMF - - Last Managed Frame -
- LOB - - Large Object Block -
- LOS - - Large Object Space -
- OS - - Operating System -
- PC - - Profile Collector -
- SIMD - - Single Instruction Multiple Data -
- SOB - - Single Object Block -
- SSA - - Single Static Assignment -
- SSE, SSE2 - - Streaming SIMD Extensions (2) -
- STL - - Standard Template Library -
- TBS - - Time-based Sampling -
- TLS - - Thread Local Storage -
- TM - - Thread Manager -
- VM - - Virtual Machine, same as JVM in current document -
-

- Back to Top -

-

- 2. VM Architecture -

-

- 2.1 Overview -

-

- The Dynamic Runtime Layer (DRL) is a clean-room implementation of the - Java* 2 Platform, Standard Edition (J2SE*) 1.5.0. This Java* run-time environment - consists of the virtual machine (DRLVM), and a set of Java* 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. -

-

- Key features of DRL include the following: -

-
    -
  • - Modularity: Functionality is grouped into a limited number - of coarse-grained modules with well defined interfaces. - -
  • - Pluggability: Module implementations can be replaced at - compile time or run time. Multiple implementations of a given - module are possible. - -
  • - Consistency: Interfaces are consistent across platforms. - -
  • - Performance: Interfaces fully enable implementation of - modules optimized for specific target platforms. - -
-

- 2.2 About Components -

-

- The DRL virtual machine reconciles high performance with the extensive - use of well-defined interfaces between its components. -

-

- 2.2.1 Components, Interfaces, and Instances -

-

- A component 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 2.2.2 Linking Models. -

-

- DRLVM components communicate via functional interfaces. An - interface 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 - default interface to communicate with the component manager, and one or more interfaces - for communication with other components. -

-

- Note -

-

- In the current version, only the execution manager uses the component - manager. Other components will migrate to this new model in further - releases. -

-

- DRL can also operate with co-existing component instances, as requires - the Invocation API [7]. An - instance of a component contains a pointer to its default - interface and - component-specific data. The porting layer - 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. -

-

- Background -

-

- In Java* 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* - 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.
- The component manager enables - explicit creation of component instances by exposing the - CreateNewInstance() function, which corresponds to the - Java* operator new(). Components with - only one instance correspond to static class methods in Java*. All components are initialized at load time. -

-

- Subsequent sections define each component and provide information on - public interfaces, dependencies and other component specifics. -

-

- 2.2.2 Linking Models -

-

- Libraries corresponding to different DRL components are linked by one - of the following models: -

-
    -
  • - 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 8.2 Component - Manager. - -
  • - 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. - -
  • - Third-party components shipped as dynamic libraries, such as the - memory manager, are also loaded at run time. - -
-

- Back to Top -

-

- 2.3 Major DRL Components -

-

- Figure 1 below displays the major DRL components and their interfaces. -

-

- Major DRL Components -

-

- Figure 1. Major DRL Components -

-

- Figure 1 demonstrates the DRL Java* virtual machine - major components, and the class libraries that support the machine. - These components are responsible for the following functions: -

-
    -
  • - Class libraries include a set of - classes and interfaces that constitute the application programming - interface (API) for the Java* run-time - environment. The Java* class libraries (JCL) - complement the virtual machine to make up the Dynamic Runtime - Layer. -

    - The other components listed below make part of the DRL virtual - machine. -

    - -
  • - VM core with its subcomponents concentrates - most JVM control functions. - -
  • - Execution engine is the generic term for components that - execute bytecode or prepare it for execution. DRLVM - currently features the following execution engines: -
      -
    • - The Jitrino.opt optimizing JIT - compiler, which compiles code keeping reasonable balance - between compilation time and quality of the generated code. - -
    • - The Jitrino.JET 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. - -
    • - The Interpreter for easier - debugging. - -
    - -
  • - Execution manager selects the execution engine - for compiling a method, handles profiles and the dynamic - recompilation logic. - -
  • - Garbage collector allocates Java* objects in the heap memory and reclaims unreachable - objects by using the mark sweep and compaction algorithm. - -
  • - Porting layer 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 [14]. - -
-

- 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. -

-

- Back to Top -

-

- 2.4 Data Structures -

-

- This section provides an overview of data structures in DRLVM, typical - examples of data structures, and the exposed data layout of public - data structures. -

-

- In DRLVM, all data structures are divided into the following groups: -

-
    -
  • - Private data structures can only be used inside a specific DRLVM component. - Other components can only access such data structures via exported component interfaces. -
  • - Public data structures shared across different DRLVM - components as listed in this section. - -
-

- For example, when compiling an access operation to an instance field, - the JIT calls the public VM_JIT 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. -

-

- 2.4.1 Object Layout -

-

- DRLVM exports data structures in accordance with the JNI [5] and JVMTI [4] 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 jobject, and DRLVM - defines it as illustrated below. -

- 
-typedef struct ManagedObject {
-  VTable *vt;
-  uint32 obj_info;
-  /* Class-specific data */
-} ManagedObject;
-struct _jobject { ManagedObject* object; }
-typedef struct _jobject*  jobject;
-
-

- The jobject structure contains the following elements: -

-
    -
  • - The vt field points to the object virtual-method - table. -

    - Each class has one virtual-method - table (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. -

    - -
  • - The obj_info 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. - -
-

- Class-specific instance fields immediately follow the vt - and obj_info 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. -

-
-
- Example -
-
- The excerpt of code below illustrates the usage of an object - structure in DRLVM for the GetBooleanField() JNI - function. -
-
-
-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
-
-

- 2.4.2 Compressed References -

-

- To decrease memory footprint on 64-bit platforms [11], direct object and VTable pointers are - compressed in the Java* heap to 32-bit values. -

-

- 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. -

-

- Apart from the basic assumptions about object layout and the VTable - cache, all interaction between major DRLVM components is achieved - through function calls. -

-

- Back to Top -

-

- 2.5 Initialization -

-

- 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 [7], and initialization follows the sequence - described below. The subsection 2.5.3 - Destroying the VM below also describes the virtual machine - shutdown sequence. -

-

- The main(…) function is responsible for the major - stages of initialization sequence and does the following: -

-
    -
  1. - Initializes the logger - -
  2. - Performs the first pass arguments parsing - -
  3. - Creates a VM instance by calling the create_vm() - function - -
  4. - Runs the user application by calling the VMStarter.start() method - -
  5. - Destroys the VM instance by calling the destroy_vm() - function - -
-

- The subsequent sections describe these initialization stages in - greater detail. -

-

- 2.5.1 First pass Arguments Parsing -

-

- At this stage, the VM splits all command-line arguments into the - following groups: -

-
    -
  • - <vm-arguments> for initializing the VM instance - -
  • - <class-name | -jar jar-file> for the name or - class or .jar file - -
  • - <java-arguments> for the user application - -
-

- The virtual machine then creates the JavaVMInitArgs - structure from <vm-arguments>. -

-

- 2.5.2 Creating the VM -

-

- The create_vm() function is a prototype for - JNI_CreateJavaVM() responsible for creating and - initializing the virtual machine. This function does the following: -

-
    -
  1. - For Linux* platforms, initializes the threading - system.
    - No actions are performed on Windows* platforms. - Other steps apply to both operating systems. - -
  2. - 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. -
      -
    1. - Creates synchronization objects. - -
    2. - Initializes the VM_thread structure and stores - the structure in the thread local storage. - -
    - -
  3. - Initializes the VM global synchronization locks. - -
  4. - Creates the component manager. - -
  5. - Loads the garbage collector and interpreter libraries. - -
  6. - Initializes basic VM properties, such as java.home, - java.library.path, and - vm.boot.class.path, according to the location of the - VM library.
    - The list of boot class path .jar files is hard-coded - into the VM library. Use –Xbootclasspath - command-line options to change the settings. - -
  7. - Initializes system signal handlers. - -
  8. - Parses VM arguments. - -
  9. - Initializes JIT compiler instances. - -
  10. - Initializes the VM memory allocator. - -
  11. - Initializes the garbage collector by calling gc_init(). - -
  12. - Preloads basic API native code dynamic libraries. -

    - Note -

    -

    - The vm.other_natives_dlls property defines the list - of libraries to be loaded. -

    - -
  13. - Initializes the JNI support VM core component. - -
  14. - Initializes the JVMTI support functionality, loads agent dynamic - libraries. At this step, the primordial phase starts. - -
  15. - Attaches the current thread and creates the M2nFrame at the top of the stack (step 2). - -
  16. - Initializes the bootstrap class loader. - -
  17. - Preloads the classes required for further VM operation. - -
  18. - Caches the class handles for the core classes into the VM - environment. - -
  19. - Attaches the current thread (step 3). -
      -
    1. - Creates the java.lang.Thread object for the - current thread. - -
    2. - Creates the thread group object for the main thread group and - includes the main thread in this group. - -
    3. - Sets the system class loader by calling - java.lang.ClassLoader.getSystemClassLoader(). - -
    - -
  20. - Sends the VMStart JVMTI event. This step begins the - start phase. - -
  21. - Sends the ThreadStart JVMTI event for the main thread. - Send the VMInit JVMTI event. At this stage, the - live phase starts. - -
  22. - Calls the VMStarter.initialize() method. - -
-

- 2.5.3 Destroying the VM -

-

- The destroy_vm() function is a prototype for - JNI_DestroyJavaVM() responsible for terminating operation - of a VM instance. This function calls the VMStarter.shutdown() method. -

-

- 2.5.4 VMStarter class -

-

- This Java* class supports specific VM core tasks by - providing the following methods: -

-
-
- initialize() -
-
- Called by the create_vm() method, does the following: -
    -
  • - Starts the finalizer and execution manager helper threads - -
  • - Registers the shutdown hook for proper helper threads - shutdown - -
-
-
- shutdown() -
-
- Called by the destroy_vm() method, does the following: - -
    -
  • - Waits for non-daemon threads - -
  • - Calls the System.exit() method - -
-
-
- start() -
-
- Runs the user application: -
    -
  • - Initializes the system class loader - -
  • - Loads the main class of the application - -
  • - Obtains the main() method via reflection - -
  • - Starts the thread that invokes the main() method - and caches exceptions from this method - -
-
-
-

- Back to Top -

-

- 2.6 Root Set Enumeration -

-

- DRLVM automatically manages the Java* heap by using - tracing collection techniques. -

-

- 2.6.1 About Roots -

-

- Root set enumeration is the process of collecting the initial - set of references to live objects, the roots. 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. -

-

- Roots consist of: -

-
    -
  • - Global references, such as static fields of classes, JNI global handles, - interned string references -
  • - Thread-specific references in managed stack frames, local JNI - handles, and the per-thread data structures maintained by the VM - core - -
-

- 2.6.2 Black-box Method -

-

- In DRLVM, the black-box method is designed to accommodate - precise enumeration of the set of root references. The GC considers - everything outside the Java* 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. -

-

- Enumeration of a method stack frame is best described in terms of safe - points and GC maps. The GC map 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 safe - point. 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. -

-

- Back to Top -

-

- 2.6.3 Enumeration Procedure -

-

- When the GC decides to do garbage collection, it enumerates all roots - as described below. -

-
    -
  1. - The garbage collector calls the VM core function - vm_enumerate_root_set_all_threads(). -

    - Note -

    -

    - Currently, the DRLVM implementation does not support concurrent - garbage collectors. -

    - -
  2. The - VM core suspends all threads, see section 3.5.4 Safe Suspension. -
  3. - 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.
    - 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 - JIT_get_root_set_from_stack_frame() and - JIT_unwind_stack_frame(). -
      -
    1. - The VM identifies the method that owns the stack frame by looking - up the instruction pointer value in the method code block - tables. - -
    2. - The VM passes the instruction pointer and the stack pointer - registers to the JIT compiler. - -
    3. - The JIT identifies the safe point and finds the GC map associated - with the code address. - -
    4. - 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 gc_add_root_set_entry() for each stack - location, which contains pointers to the Java* heap [12].
      - The interpreter uses its own stack frame format and - enumerates all thread stack trace when the interpreter - function interpreter_enumerate_thread() is - called. - -
    - -
  4. The - VM core and the execution engine communicate the roots to the garbage collector - by calling the function - gc_add_root_set_entry(ManagedObject). - -

    - Note -

    -

    - 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. -

    -
  5. The - VM core returns from - vm_enumerate_root_set_all_threads(), 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. - -
  6. - The GC determines the set of reachable objects by tracing the reference - graph. In the graph, Java* objects are vertices - and directed edges are connectors between the objects having - reference pointers to other objects. - -
  7. - The GC calls the VM function vm_resume_threads_after(). - The VM core resumes all threads, so that the garbage collector can - proceed with the allocation request that triggered garbage - collection. - - -
-

- Back to Top -

-

- 2.7 Finalization -

-

- Finalization is the process of reclaiming unused system - resources after garbage collection. The DRL finalization fully - complies with the specification [1]. The - VM core and the garbage collector cooperate inside the virtual machine - to enable finalizing unreachable objects. -

-

- Note -

-

- 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. -

-

- 2.7.1 Finalization Procedure -

-

- As Figure 2 shows, several queues can store references to finalizable - objects: -

-
    -
  • - GC live objects queue for marked objects. - -
  • - GC buffering queue for unmarked objects. This queue is - empty most of the time. - -
  • - VM core queue for objects unreachable from the root and - scheduled for finalization. - -
-

- Object Queues in VM and GC -

-

- Figure 2. Finalization Framework -

-

- 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. -

-

- Back to Top -

-
    -
  1. -

    - Object Allocation -

    -

    - During object allocation, the - garbage collector places references to finalizable objects into - the live object queue, as shown in Figure 3. Functions - gc_alloc() and gc_alloc_fast() - register finalizable objects with the queue. -

    -

    - - -

    -

    - Figure 3. Allocation of Finalizable Objects -

    - -
  2. -

    - After Mark Scan -

    -

    - 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. -

    -

    - - -

    -

    - Figure 4. Unmarked Objects Queue Usage -

    - -
  3. -

    - Filling in the Finalizable Objects Queue -

    -

    - 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 - vm_finalize_object() function for each reference - until the unmarked objects queue is empty. -

    -

    - - -

    -

    - Figure 5. Finalization Scheduling -

    - -
  4. -

    - Activating the Finalizer Thread -

    -

    - Finally, the GC calls the vm_hint_finalize() - function that wakes up finalizer threads. All finalizer threads - are pure Java* threads, see section 2.7.2 Work Balancing Subsystem.
    - Each active thread takes one object to finalize and does the - following: -

    -
      -
    1. - Gets references to the object from the VM queue - -
    2. - Removes the reference from the queue - -
    3. - Calls the finalize() function for the object - -
    -

    - 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. -

    -

    - - -

    -

    - Figure 6. Finalizer Threads -

    - -
-

- Back to Top -

-

- 2.7.2 Work Balancing Subsystem -

-

- 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. -

-

- The work balancing subsystem operates in the following stages: -

-
-
- Stage 1: Permanent finalizer threads only -
-
- 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. -
-
- Stage 2: Temporary finalizer activated -
-
- 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).
- At this stage, the garbage collector calls the - vm_hint_finalize() function before performing the - requested allocation. This function is also called after each - garbage collection. The vm_hint_finalize() 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.
- 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. -

- Note -

-

- The work balancing subsystem checks whether the finalization - queue is empty, but does not take into account the number of - objects in the queue. -

-
-
  - -
-
- Stage 3: Temporary finalizer threads destroyed -
-
- 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.
- When the finalization queue is empty, temporary threads are - destroyed and the work balancing cycle restarts. -
-
-

- WBS Internals -

-

- Assuming that N is an indefinite optimum number of finalizer threads, - you can make the following conclusions: -

-
    -
  • - Number N-1 finalizer threads is not enough, and all the Java* heap gets filled with finalizable objects. - -
  • - Number N+1 threads is an excess quantity that will cause certain - threads to wait. - -
  • - N threads is the optimum solution, however, this cannot be achieved - if N is unknown. - -
-

- 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: -

-
    -
  1. - 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. - - -
  2. - 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. - -
  3. - When the queue is empty, temporary threads are destroyed, as - described in stage 3. - -
-

- Figure 7 below demonstrates variations in the number of finalizer - threads over time. -

-

- - -

-

- Figure 7. Variations in Number of Running Finalizer Threads -

-

- As a result, the number of running finalizer threads in the current - work balancing subsystem can vary between 0 and 2N. -

-

- Note -

-

- The maximum value for 2N is 256 running finalization threads. -

-

- Back to Top -

-

- 3. VM Core -

-

- 3.1 Architecture -

-

- 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 [1] and of elements specific - for the DRLVM implementation, as follows: -

-
    -
  • - Class support 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. - -
  • - Kernel classes component includes a - subset of the Java* class library closely tied - with the virtual machine, which mostly includes classes of the - java.lang package. - -
  • - Kernel class native methods - link the Java* kernel classes with other DRLVM - components, and are exported as ordinary native methods from the VM - executable according to the Java* Native Interface - (JNI) specification [5]. - -
  • - JNI support component supports execution - of native methods for Java* classes, and for the - native interface API [5]. - -
  • - JVMTI support enables loading of the - debugging agent, and provides functionality for running simple - debug scenarios, see the JVM Tool Interface Specification [4]. - -
  • - Stack support allows stack examination - for creating stack traces and performing enumeration of live - references. - -
  • - Exception handling 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. - -
  • - VM services 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. - -
  • - Verifier checks the classes to meet safety - requirements before class loading. - -
  • - Thread management functionality - provides threading inside the virtual machine. - -
  • - Utilities are used by the VM core during - normal operation. - -
-

- 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 [1]. Figure 8 shows the VM - core overall structure and the internal logic of components - interaction. For more details on available interfaces, see 3.13 Interfaces. -

- - - - - - - -
- VM Core Components and Interfaces -
-

- Figure 8. VM Core - Components -

-

- Red font indicates external interfaces. -

-
-

- Back to Top -

-

- 3.2 Class Support -

-

- The class support component processes classes in accordance with the - JVM specification [1], 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 - RedefineClasses() and GetLoadedClasses() use - utility interfaces provided by class support. -

-

- The class support component has the following major goals: -

-
    -
  • - Load binary class data from .class files and - .jar archives from the bootstrap class loader - -
  • - Create internal (VM) representations of classes from byte arrays - -
  • - Provide access to information on classes, methods, and fields for - various VM modules - -
  • - Provide instruments for class redefinition and class support - related events required for JVMTI - -
  • - Communicate with the verifier on verification of methods bytecode - -
-

- 3.2.1 Classification of Class Support Interfaces -

-

- Class support functions can be divided into the following groups: -

-
-
- Class Loading -
-
- Comprises functions for loading classes, searching for loaded - classes inside VM structures, and JVMTI class redefinition. The - functions obtain bytes from the Java* class - libraries via the descendants of the - java.lang.ClassLoader class or from the files and - directories listed in the vm.boot.class.path property. - These functions also bind loaded classes with the defining class - loader and provide information on all loaded classes. -
-
-
-
- Class Manipulation -
-
- Provides access to class properties, such as the internal (VM) and - the external (Java*) names, access and properties - flags, the super-class and the defining class, as well as super - interfaces, inner classes, methods, fields, and attributes.
- Supports class resolution by resolving symbolic references - in the run-time constant pool of the class. -
-
-
-
- Method Manipulation -
-
- 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.
- Functions of this group also enable adding new versions of - JIT-compiled methods code and storing service information about - compiled code. -
-
-
-
- Field Access -
-
- 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. -
-
-
-
- Type Access -
-
- 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* virtual machines, for example, - with the ECMA Common Language Infrastructure. Type access functions - provide descriptions of both Java* types, such as - managed pointers, arrays, and primitive types, and non-Java* types, such as non-managed pointers, method pointers, - vectors, unboxed data, and certain unsigned primitive types. -
-
-

- 3.2.2 Internal Class Support Data Structures -

-

- The VM core stores information about every class, field, and method - loaded as described below. -

-
    -
  • - Class data structure 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. - -
  • - Field data structure 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. - -
  • - Method data structure contains the information on methods - similar to the field data structure content. - -
-

- Back to Top -

-

- 3.3 Native Code Support -

-

- The native code support component consists of two parts, execution of - native methods used by Java* classes, and an - implementation of the Java* Native Interface (JNI) - API for native code. Execution of native methods is required by the - Java* Language Specification [2] and JNI is required by JNI Specification - [5]. -

-

- 3.3.1 Execution of Native - Methods -

-

- The virtual machine calls native methods differently with the JIT and - with the interpreter as described below. -

-
    -
  • - When the JIT is used, the virtual machine generates special - wrappers for calling native methods, which perform synchronization - for synchronized native methods and record information for stack unwinding and enumeration of - references used in native code. The wrapper code is generated for a - native method when the method is called for the first time, and - further on, the wrapper is called from JIT-compiled code directly. - -
-

- JNI optimizations -

-

- 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. -

-
    -
  • - In the interpreter mode, native code is called directly with - static stubs, and the interpreter performs all the operations done - by wrappers in the JIT execution mode. - -
-

- 3.3.2 JNI Support -

-

- The Java* Native Interface is a set of functions, - which enable native code to access Java* classes, - objects, methods, and all the functionality available for a regular - method of a Java* class. -

-

- 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. -

-
-
- Example -
-
-

- The following code is implementation of the - IsAssignableFrom JNI function, which uses the class - support interface: -

-
-#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
-
-

- Back to Top -

-

- 3.4 Stack Support -

-

- 3.4.1 About the Stack -

-

- The stack is a set of frames created to store local method - information. The stack is also used to transfer parameters to the [... 12512 lines stripped ...]