SOFTWARE REQUIREMENT SPECIFICATION
OpenDos
The OpenSource
Dynamic Optimization System
Introduction
1.1Purpose.
Dynamic optimization refers to the runtime optimization of a native program binary. Dynamic binary translation is an important area for compiler research, because additional information available at runtime can substantially improve the effectiveness of optimizations.
The challenge is to monitor a process during its execution. We are building a system for monitoring and modifying a program’s behavior while it is running. The runtime environment exposes several execution paths that have not been discovered during static optimization. This gives us several opportunities for performing optimizations even though the binary is statically optimized.
The lightweight dynamic binary optimizer is software that optimizes the executables at run-time. This optimizer is aimed to optimize i386 executables .It is an entirely a user-level software which works on the native binaries.
This SRS describes the functions and performance requirements of the optimizer.
1.2Document Conventions
1.3 Intended audience
This SRS is intended for the developers and users.
1.4 Scope of the Development Project
Context:
The aim of our project is to develop a Dynamic optimization system. The function of this system will be to generate a more optimized version of the executable at the run time and gain performance. We bootstrap into the executable by compiling the system as a pre-loadable library and finally integrate it with the executable.
Information Objective:
Our project doesn’t accept anything as input; it is transparent enough to integrate itself to the binary, which is going to be executed. We actually find the hot codes in the executable and after converting them into an optimized version; we execute it natively on the machine. The output is the performance gain that we achieve by optimizing those fragments, which are optimized.
Function and performance:
Our software will first be loaded into the address space of the executable, which is going to be executed. Then it tries to bootstrap into the executable and take the control from it and then interpret the code that was going to be executed.
No performance gain will be achieved in the initial phase of execution but later on, once most of the hot regions are identified, there will be gain in the performance.
Limitations:
1. Takes away cycles from program.
2. Especially slow at start.
3. Debugging can be difficult:
1.5. Definitions, Acronyms, and Abbreviations
DOS : Dynamic optimizer system .
1.6 Refernces
1.7 Overview of document
Overall description
2.1 Product perspective
The dynamic optimizer is a user level system. It consists of various shared library modules. These are invoked as soon as the executable is loaded. They are loaded before the other DLLs. The system intercepts the control from the executable and control is given to the dynamic optimizer system (DOS).
The DOS executes the executable by monitoring it that is executable executes under the control of the DOS. As the 90-10 rule 90% of the program execution time is used for 10% of the program region. The main aim of the DO is to identify this 10% and optimize it.As the binaries shipped by the vendors are not fully optimized there are various opportunities for optimizing these binaries. Also as optimization is done at runtime no extra code is added to the binary.
Also DOS exploit the runtime information available to them. This includes information about the taken branches, frequently executed path etc., which allows the DOS to perform path specific optimizations. Using this information we can apply certain optimizations, which are termed aggressive during static compilation.
2.2 Product functions
The functions of the DOS are
1.Find the hotspots in the program.
2.Optimize these hotspots using appropriate optimization techniques.
3.Cache these optimized hotspots in a software code cache.
4.On subsequent encounter of the same hot code execute from the code cache.
2.3 User classes.
This optimizer is user level software and intended to make the executable run faster.
It can be used
1. To run application software.
2. To run legacy applications where recompiling is very costly which thus provides ample opportunities for optimizations.
2.4 Operating environment.
The optimizer works in user space.
It is designed for the i386 architecture to run Linux executables.
2.5 Design and Implementation Constraints
The executable should be an i386 executable.
2.6 User Documentation
2.7 Assumptions and Dependencies
2.8 Overview of Data Requirements
2.9 General Constraints, Assumptions, Dependencies, Guidelines
2.10 User View of Product Use
The user will be provided with an option whether he wants to run the application under our DOS (Dynamic Optimizer System). This the user can do by specifying as the command line argument –DOS if he intents to run his application under DOS.
3 External interface requirements
3.1 User interfaces (not applicable)
3.2 Hardware interfaces (not applicable).
3.3 Software interfaces
We use the Binary File Descriptor (BFD) library for handling the executable.
BFD is a library, which provides a single interface to read and write object files, the other DLLs. It makes changes in the ELF header so that control transfers to DOS after all DLLs are loaded and initializations are made.
Inputs.
The input to this preload library is the handle to the executable.
Output
After this function the control will be with the next module.
4.System Features
4.1. Hot path (trace) selection.
Once we get control, we have to execute the executable.
For this we require 2 functions
1.Disassembling
2.Hot path selection.
1. Disassembly
Disassembler disassembles each instruction of the object code selectively.
2.Hot path selection.
The disassembled instruction is examined for control transfer instructions and hot path selector maintains this information. The non-control transfer instructions are copied as they are without disassembling to a page. A block of sequential instructions between two control transfer instructions is executed natively. Whenever there is a back edge the target of the back edge to the origin of the back edge itself is considered as candidate for a hot trace as it forms a loop. Then a count is maintained for this trace, which when exceeds the threshold level is considered as a hot trace and given for further optimization.
Inputs
The input is the start address of the main function of the executable. This address is obtained from the ELF header.
Output
The output is selected hot path.
Also each disassembled instruction is executed.
4.2.Optimization.
Purpose
This function is to optimize the hot path obtained. The trace is analyzed and suitable optimization techniques are used to optimize it. Here a cost-benefit analysis is performed to select the appropriate optimization techniques to be applied.
Input
The input is selected hot trace.
Output
The output is optimized trace, which is emitted into the code cache.
4.3.Caching the trace in code cache.
Purpose:
The optimized trace is assembled and put into software code cache. This is to ensure that the next reference to this trace is executed from the code cache. The code cache is located in the same address space as the executable and is allocated during initialization of DOS.
The main aim is to bring the whole 10% path frequently executing code inside the code cache so that the execution remains in the code cache for most of its time.
Input
The input is optimized hot trace.
Output
The output is the cached trace.
5.6 Special User Requirements
5.6.1 Backup and Recovery
5.6.2 Data Migration
5.6.3 Data retention
5.6.4 User Training
5.6.5 Installation
The OpenSource
Dynamic Optimization System
Introduction
1.1Purpose.
Dynamic optimization refers to the runtime optimization of a native program binary. Dynamic binary translation is an important area for compiler research, because additional information available at runtime can substantially improve the effectiveness of optimizations.
The challenge is to monitor a process during its execution. We are building a system for monitoring and modifying a program’s behavior while it is running. The runtime environment exposes several execution paths that have not been discovered during static optimization. This gives us several opportunities for performing optimizations even though the binary is statically optimized.
The lightweight dynamic binary optimizer is software that optimizes the executables at run-time. This optimizer is aimed to optimize i386 executables .It is an entirely a user-level software which works on the native binaries.
This SRS describes the functions and performance requirements of the optimizer.
1.2Document Conventions
1.3 Intended audience
This SRS is intended for the developers and users.
1.4 Scope of the Development Project
Context:
The aim of our project is to develop a Dynamic optimization system. The function of this system will be to generate a more optimized version of the executable at the run time and gain performance. We bootstrap into the executable by compiling the system as a pre-loadable library and finally integrate it with the executable.
Information Objective:
Our project doesn’t accept anything as input; it is transparent enough to integrate itself to the binary, which is going to be executed. We actually find the hot codes in the executable and after converting them into an optimized version; we execute it natively on the machine. The output is the performance gain that we achieve by optimizing those fragments, which are optimized.
Function and performance:
Our software will first be loaded into the address space of the executable, which is going to be executed. Then it tries to bootstrap into the executable and take the control from it and then interpret the code that was going to be executed.
No performance gain will be achieved in the initial phase of execution but later on, once most of the hot regions are identified, there will be gain in the performance.
Limitations:
1. Takes away cycles from program.
2. Especially slow at start.
3. Debugging can be difficult:
1.5. Definitions, Acronyms, and Abbreviations
DOS : Dynamic optimizer system .
1.6 Refernces
1.7 Overview of document
Overall description
2.1 Product perspective
The dynamic optimizer is a user level system. It consists of various shared library modules. These are invoked as soon as the executable is loaded. They are loaded before the other DLLs. The system intercepts the control from the executable and control is given to the dynamic optimizer system (DOS).
The DOS executes the executable by monitoring it that is executable executes under the control of the DOS. As the 90-10 rule 90% of the program execution time is used for 10% of the program region. The main aim of the DO is to identify this 10% and optimize it.As the binaries shipped by the vendors are not fully optimized there are various opportunities for optimizing these binaries. Also as optimization is done at runtime no extra code is added to the binary.
Also DOS exploit the runtime information available to them. This includes information about the taken branches, frequently executed path etc., which allows the DOS to perform path specific optimizations. Using this information we can apply certain optimizations, which are termed aggressive during static compilation.
2.2 Product functions
The functions of the DOS are
1.Find the hotspots in the program.
2.Optimize these hotspots using appropriate optimization techniques.
3.Cache these optimized hotspots in a software code cache.
4.On subsequent encounter of the same hot code execute from the code cache.
2.3 User classes.
This optimizer is user level software and intended to make the executable run faster.
It can be used
1. To run application software.
2. To run legacy applications where recompiling is very costly which thus provides ample opportunities for optimizations.
2.4 Operating environment.
The optimizer works in user space.
It is designed for the i386 architecture to run Linux executables.
2.5 Design and Implementation Constraints
The executable should be an i386 executable.
2.6 User Documentation
2.7 Assumptions and Dependencies
2.8 Overview of Data Requirements
2.9 General Constraints, Assumptions, Dependencies, Guidelines
2.10 User View of Product Use
The user will be provided with an option whether he wants to run the application under our DOS (Dynamic Optimizer System). This the user can do by specifying as the command line argument –DOS if he intents to run his application under DOS.
3 External interface requirements
3.1 User interfaces (not applicable)
3.2 Hardware interfaces (not applicable).
3.3 Software interfaces
We use the Binary File Descriptor (BFD) library for handling the executable.
BFD is a library, which provides a single interface to read and write object files, the other DLLs. It makes changes in the ELF header so that control transfers to DOS after all DLLs are loaded and initializations are made.
Inputs.
The input to this preload library is the handle to the executable.
Output
After this function the control will be with the next module.
4.System Features
4.1. Hot path (trace) selection.
Once we get control, we have to execute the executable.
For this we require 2 functions
1.Disassembling
2.Hot path selection.
1. Disassembly
Disassembler disassembles each instruction of the object code selectively.
2.Hot path selection.
The disassembled instruction is examined for control transfer instructions and hot path selector maintains this information. The non-control transfer instructions are copied as they are without disassembling to a page. A block of sequential instructions between two control transfer instructions is executed natively. Whenever there is a back edge the target of the back edge to the origin of the back edge itself is considered as candidate for a hot trace as it forms a loop. Then a count is maintained for this trace, which when exceeds the threshold level is considered as a hot trace and given for further optimization.
Inputs
The input is the start address of the main function of the executable. This address is obtained from the ELF header.
Output
The output is selected hot path.
Also each disassembled instruction is executed.
4.2.Optimization.
Purpose
This function is to optimize the hot path obtained. The trace is analyzed and suitable optimization techniques are used to optimize it. Here a cost-benefit analysis is performed to select the appropriate optimization techniques to be applied.
Input
The input is selected hot trace.
Output
The output is optimized trace, which is emitted into the code cache.
4.3.Caching the trace in code cache.
Purpose:
The optimized trace is assembled and put into software code cache. This is to ensure that the next reference to this trace is executed from the code cache. The code cache is located in the same address space as the executable and is allocated during initialization of DOS.
The main aim is to bring the whole 10% path frequently executing code inside the code cache so that the execution remains in the code cache for most of its time.
Input
The input is optimized hot trace.
Output
The output is the cached trace.
5.6 Special User Requirements
5.6.1 Backup and Recovery
5.6.2 Data Migration
5.6.3 Data retention
5.6.4 User Training
5.6.5 Installation
posted by Sandeep at 2:00 AM
0 Comments:
Post a Comment
<< Home