Apache Harmony is retired at the Apache Software Foundation since Nov 16, 2011.

The information on these pages may be out of date, or may refer to resources that have moved or have been made read-only.
For more information please refer to the Apache Attic

DRLVM Execution Manager

Execution Manager Component Description

  1. About This Document
    1. Purpose
    2. Intended Audience
    3. Using This Document
    4. Conventions and Symbols
  2. Overview
    1. Key Features
  3. Architecture
    1. Execution Manager in VM
    2. Profile Collector
      1. EM_PC Interface
      2. How to plug in a custom PC
    3. Profiler Thread
  4. Processes
    1. Recompilation
    2. Execution Management
      1. Instantiation
      2. Method Execution
  5. Public Interfaces
    1. EM_VM Interface
    2. EM_JIT Interface
  6. References

About This document


This document describes the internal structure of the execution manager component deployed with the virtual machine as part of the DRL (Dynamic Runtime Layer) initiative. The description covers the internal design of the execution manager and its interaction with other DRLVM components. The document is targeted at DRLVM developers with special interest in code execution algorithms. The information can be helpful for future development of DRL execution management techniques and can serve as an example for those implementing an execution manager from scratch.

In this document, you can find implementation-specific details of the execution manager. General information on the EM role in overall virtual machine design and VM-level requirements are out of scope of this document and are covered in the DRLVM Developer's Guide [3] .

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. The document assumes that readers understand the concepts of dynamic optimizations, recompilation and profile collection.

Using This Document

The DRLVM execution manager description has the following major sections:

Conventions and Symbols

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

Back to Top


The execution manager is responsible for selecting execution engines (a JIT compiler or an interpreter) for method compilation and execution at run time. The execution manager (EM) takes input from its configuration settings and run-time profile information. The DRL execution manager also uses profile collectors to gather run-time data associated with method code and the just-in-time (JIT) compiler that produced the code. The execution manager, profile collectors, and execution engines plugged in VM make up the dynamic optimization subsystem [1], [2].

The execution manager instantiates execution engines depending on its configuration [4] and the current VM mode.

For a definition of the role of EM in the architecture of DRLVM [3].

Key Features

The key features of the DRL execution manager include the following:

Back to Top


This section of the document describes the internal architecture of the execution manager and its external connections with other components of the virtual machine. In brief, EM communicates with the VM core and with execution engine(s) at the VM level. Internally, the execution manager has a profile collector as its subcomponent, and uses internal functional interfaces to communicate with it, as described in section Profile Collector.

Execution Manager in VM

The VM core component sends requests to EM to execute methods. VM passes a method handle and parameters to the execution manager through the EM_VM interface. EM selects the engine for compiling the method and sends a compilation request to VM to compile the method with the selected engine.

Instantiating and configuring JIT compilers goes through the JIT_EM interface [3]. In its turn, the execution manager exports the EM_JIT interface for accessing method profiles and profile collectors. Specifically, the EM_JIT interface consists of two parts:

These interface interactions are shown in Figure 1 and described in detail in section Public Interfaces.

Interaction between Execution Manager, JIT, and VM

Figure 1. Execution Manager Interfaces

In the figure, several blocks of the same type identify instances of the same component, as in the case with profile collectors and JIT compilers. For details on interfaces displayed in the figure, see section Public Interfaces.

Back to Top

Profile Collector

The profile collector (PC) is a subcomponent of the execution manager that collects method profiles for Java* methods compiled by a JIT or executed by the interpreter. DRL EM instantiates and configures profile collectors according to the settings of its configuration file.

The profile collector can collect method profiles only for the methods compiled by a single JIT. To collect the same type of profile information for methods compiled by different JIT compilers, the execution manager uses different PC instances.

After PC collects a method profile, subsequent JIT compilers in the recompilation chain can re-use this profile. A JIT can only use a collected method profile if it is explicitly indicated in the EM configuration file [4]. If a JIT compiler is expected to use a method profile, the execution manager defines the JIT role, that is, configures the JIT compiler to generate or to use a specific profile in the file include/open/em.h using the following format:

enum EM_JIT_PC_Role {




With this model, instances of the compiler work independently of each other at run time. A JIT compiler can always use a PC handle to access the profile data that is assigned to be collected or used by this JIT compiler.
The profile collector does not trigger method recompilation. Instead, PC notifies the execution manager that a method profile is ready. To detect profile readiness, PC uses its own heuristics and configuration settings passed from EM during profile collector initialization. When the profile is ready, EM initiates recompilation of the method.

EM_PC Interface

The EM_PC interface handles interaction between the execution manager and the profile collectors and consists of the following function groups:

For details on the EM_PC interface functions, generate from the include/open/em_profile_access.h header file by using Doxygen.

How to Plug in a Custom PC

Currently, EM supports only statically linked profile collectors. To add a new profile collector, you must add the profile collector’s code to the EM package, add the methods specific for the new profile collector to the profile access interface and enable EM to create the new profile collector. Follow this step-by-step instruction to plug in your new profile collector into the current EM package.

  1. Extend the ProfileCollector abstract class and define all pure virtual methods. This class is in the em/src/DrlProfileCollectionFramework.h file.
  2. Add methods specific for the new profile collector to the include/open/em_profile_access.h file and register its new EM_PCTYPE.
  3. Adjust em/src/DrlEMImpl.cpp::initProfileAccess() to initialize access methods to the new profiler type with valid function pointers.
  4. Adjust em/src/DrlEMImpl.cpp::createProfileCollector() factory method to create the new profile collector type if its name is specified in the configuration file.

As an example, you can use one of the two profiler collectors in the current EM package: the entry-backedge profile collector and the edge profile collector. The entry-backedge profile collector can work in the synchronous and asynchronous modes. The synchronous mode means that the profile is checked for readiness in a user Java* thread during code execution. The asynchronous mode means that the profile readiness is checked and hot methods are detected and recompiled in a separate profiler thread managed by EM.

Profiler Thread

To enable a profile collector to check profile readiness asynchronously, the execution manager requires a special thread created by the VM core. This thread must be an ordinary Java* thread because method compilation may result in execution of JIT-compiled code during class resolution or side-effect analysis.

After loading all core classes and before executing the method main(), the execution manager starts the recompilation thread. EM configures this thread to call back in a specified period of time. During this callback, the execution manger requests profile collectors to check profiles and runs method recompilation as required.

The execution manager only starts the profiler thread when the profile collector requires asynchronous support. For example, no profiler thread support is needed when the profile check goes in parallel with code execution or is done by an external event from the PMU driver.

Back to Top



For frequently executed methods, makes sense to recompile them and to apply more aggressive optimizations. The execution manager determines the recompilation logic using recompilation chains that can connect multiple profile-compatible JIT compilers into a single recompilation queue. Recompilation chains are static and defined in the EM configuration file [4]. A method is permanently matched against one recompilation chain.

To compile a method for the first time, the execution manager calls the first JIT compiler in the chain. After profiling information about the method is collected, the next JIT in the chain is ready to recompile the method applying more aggressive optimizations. The data from the method profile can be used during method recompilation to adjust custom optimization parameters.

Recompilation chains can be useful in different modes of VM operation, as illustrated in the examples below.

Example 1. Custom profiling mode

If a compiler JIT1 does the initial method compilation with instrumentation enabled and a compiler JIT2 does the recompilation, you can avoid recompilation by redirecting certain methods to be initially compiled by a third compiler JIT3 without instrumentation. In this case, EM creates two compilation chains: the first chain contains JIT1 and JIT2, and the second chain contains JIT3. To select the chain for compiling a method, use method filters.
You may want to avoid instrumentation for class initializers or methods that already have a persistent profile collected during the previous session.

Example 2. Bug-fixing mode

A stable compiler JIT1 is used for compiling all methods except problem ones, and another one JIT2 compiles problem methods only.
This mode can be useful for localizing specific problems in a new JIT.

If multiple recompilation chains co-exist at run time, EM selects the appropriate recompilation chain to initially compile a method. Method filters associated with chains can configure the execution manager to use a specific chain for method compilation. Method filters can identify a method by its name, class name, signature or ordinal compilation number.

Execution Management

This section describes how the execution manager is involved in DRLVM operation.


Before loading an execution engine, the VM core creates an instance of the execution manager. This is the only instance used during the VM lifetime. Depending on its configuration, the execution manager initializes execution engines and profile collectors.

During JIT compiler instantiation, the execution manager:

  1. Provides the JIT with a name and registers a run-time JIT handle for it. The JIT can now use this name to distinguish its persistent settings from settings of other execution engines. A compiler can also use the handle to distinguish itself from other JIT compilers at run time.
  2. Configures the JIT to generate a new profile or to use an existing profile via the profile access interface.

    When the JIT is configured to use or generate a profile, it checks the compatibility with the given profile type. If the JIT does not support the given profile type, it can reject profile generation or usage.

Method Execution

In DRLVM, execution of a method goes as follows:

  1. VM calls the execution manager to execute a method.
  2. EM uses method filters to select the appropriate recompilation chain for each method.
  3. EM instructs the first JIT in the chain to compile a method.
  4. After the method is compiled, VM proceeds with its execution.
  5. For hot methods, EM initiates recompilation by the next JIT in the compilation chain.


A method is hot when a profile associated with it satisfies specific parameters in the PC configuration settings. For example, for an entry and back-edge profile collector, these parameters are the entry and back-edge counters' limits. When a counter value reaches the limit, the method becomes hot.

Back to Top

Public Interfaces

The execution manager interacts with the virtual machine and JIT compilers by using specific interfaces. In addition to these external interfaces, EM uses its internal interface to communicate with profile collectors. This section describes the functional interfaces that the execution manager exports for the VM core and the JIT compilers.

EM_VM Interface

The execution manager exports this interface to provide VM with method compilation and execution functions. For a detailed description of the interface, generate documentation from the em_vm.h header file by using Doxygen. For a description of the VM_EM interface made up of functions that the virtual machine exports for the execution manager, see the DRLVM Developer's Guide [3].

EM_JIT Interface

The execution manager exports this interface to enable JIT compilers to access method profiles. For details on the interface functions, generate reference documentation from files em_profile_access.h and ee_em_intf.h by using Doxygen. For a description of the JIT_EM interface made up of functions that the virtual machine exports for the execution manager, see the DRLVM Developer's Guide [3].

Back to Top


[1] Toshio Suganuma, Toshiaki Yasue, A dynamic optimization framework for a Java just-in-time compiler, http://portal.acm.org/citation.cfm?id=504296

[2] A Survey of Adaptive Optimization in Virtual Machines (2004) Matthew Arnold, Stephen J. Fink, David Grove, Michael Hind, Peter F. Sweeney http://citeseer.ist.psu.edu/arnold04survey.html

[3] DRLVM Developer's Guide, http://harmony.apache.org/subcomponents/drlvm/index.html

[4] Guide to Execution Manager Configuration, http://harmony.apache.org/subcomponents/drlvm/emguide.html

Back to Top

* Other brands and names are the property of their respective owners.