2008 International Conference on Computer Science and Software Engineering
Multithreaded optimizing technique for dynamic
binary translator CrossBit
Haibing Guan Bo Liu
Dept. of Computer Science School of software
Shanghai Jiao Tong Univ. Shanghai Jiao Tong Univ.
Shanghai, China Shanghai, China
hbguan@sjtu.edu.cn boliu@sjtu.edu.cn
Abstract—Dynamic binary translator (DBT) systems enable the
architectural incompatible platforms to execute binaries of other
architectures transparently. And binary translation and
optimization are always deemed as the key techniques to
constructing high performance DBT systems. Many previous
optimization including fragment chaining, trace/superblock
formation, translated code optimization, has been applied to
improve performance. However, seldom any effort is made to
optimize under multi-core processor environment.
Therefore, this paper describes the new multiple threads
execution engine (MTEE) of the dynamic binary translator
CrossBit, which is a both resourceable and retargetable
infrastructure for cross binary translation. The multithreaded
technique decomposes the common binary transltation working
routine into dynamic translation and translated code execution
phases, and then multi-threads enable parallelized translation of
host binaries. As a result, the multithreaded optimizing
technique accelerates the translation of binaries.
We evaluated our binary translation system across the SPEC
CPU2000 and found that the system under MTEE has reached a
performance level equal to that of the conventional CrossBit
engine which was executed on the IA32 multi-cores processor
environment. And several SPEC benchmark programs even
show that the MTEE have speed up the execution of CrossBit
about 30% at best. And we are still looking forward to a higher
performance improvement through this new software pipelined
method.
Keywords-MTEE; DBT; Dynamic Optimization; CrossBit;
I. INTRODUCTION
Dynamic translation comes as the most popular simulation
approach to running existed binaries of established platforms.
It eliminates the high overhead of frequent guest-to-host
platform instructions converting by caching the translated
native binaries into a software cache sub-system, which is
always called the translated cache (TCache). The dynamic
translation method changes the binaries of the guest platform
into a host representation which is called the translated code,
performs execution natively, and thus sets up the virtualized
guest platform environment. Systems such as dynamic binary
translation (DBT) [2][4][6] are estimated to have better
performance than most simulation system using interpretation
method, widely used for various purposes, getting involved in
This work was supported by the National Nature Science Foundation of
China under Grant No. 60773093, the National Grand Fundamental Research
973 Program of China under Grunt No.2007CB316506, the 863 Research and
Development Program of China under Grunt No. 2006AA01Z169.
978-0-7695-3336-0/08 $25.00 © 2008 IEEE
DOI 10.1109/CSSE.2008.32
Tingtao Li Alei Liang
School of software School of software
Shanghai Jiao Tong Univ. Shanghai Jiao Tong Univ.
Shanghai, China Shanghai, China
ltt@sjtu.edu.cn liangalei@sjtu.edu.cn
the fields like program instrumentation, dynamic optimization,
security, etc, and continues to expand its application areas.
High performance is deemed as the nature of the DBT
systems. The caching and reusing of translated code would
ordinarily make the DBT system ten times faster than the
conventional interpretation emulation systems or more.
However, there are lots of factors affecting the performance.
With different system configurations and execution
environment, the processing of the DBT system shows
different features, and the key factors affecting the system
differ. It results in the increasing difficulties for constructing
effective DBT systems.
There are still some general techniques conductive to
performance improvement. In the dimension of the running
DBT application, the translator could be viewed as two parts:
the runtime (RT for short) part and the target code (TC for
short) part. Here the RT represents the DBT application itself.
And the optimization DBT system always is destined to the
two major goals:
• Reduce the RT overhead,
• Speed up the TC execution
Normally, if a DBT system has the ability to consecutively
execute the translated code natively in most of the time, rarely
with any interruption by the RT, it is considered to have
eliminated most of the DBT runtime overhead. The most
popular approach to reach consecutive TC execution is the
fragment chaining (or block linking) method. The linking of
translated code block effectively reduces the control
transferring between RT and TC and brings another ten times
speed-up statistically. It is considered the most efficient
method in addition to the caching translated code.
Another common DBT implement of runtime overhead
elimination is called the traces/superblocks formation. Such
trace/superblock could be a control flow on a hot path which
is composed of several translated code blocks. The execution
on traces/superblocks is even more efficient than on basic
blocks linked because it removes control flow joint points and
doesn’t have to transfer control between blocks.
On the other hand, to speed up the TC execution, the DBTs
have to make efforts to optimize both the pre-execution (the
translating) process and the post-execution optimization
945
(always the superblock formation, etc) of translated code
blocks. These optimizations intend to improve the quality of
the translated code on the fly. It mainly involves the mapping
of the guest/host registers, the selection of register mapping
algorithm, etc. Especially, many compiler optimizations have
been applied dynamically to speed up the DBT system at post
block execution time. Researches related are called the
dynamic optimization, and are being widely studied. However,
this is beyond the scope of this paper.
To sum up, with the above approaches, the DBT systems
have reached a much better performance level than ever
before. However, as the processor technology evolutes into a
new age in which the multiple processing units (always refer
to the multi-core technology) empowers the computer systems
to high performance, multiple threading software architecture
that can fully make use of processors’ power provides the
DBT system another chance to be more powerful than before.
Accordingly, the best practise is to decompose the tasks of the
DBT systems into different parts, irrespective of the
dependencies. And working threads can then take these parts
separately. These threads are considered either as
programmable software pipeline stages or single co-workers
for applications broken down to independent subordinate
routines. If the overhead to overcome dependencies is cheaper
than serial execution, the DBT system may have the
opportunity to be enhanced by proper task decomposition and
parallelized execution.
There are two major contributions of the paper. First, this
paper reveals the major stages affecting DBT CrossBit
performance, and also analyzes their relationship. And finally,
it depicts the relationship of these stages and the performance
of CrossBit with some formulas. Second, this paper gives the
evaluation result of the new MTEE of CrossBit, which
decomposes the common DBT working routine into dynamic
translation and native binaries execution phases, and then
multi-threads them to enable parallelized translation of guest
binaries. The evaluation results show MTEE’s ability of
pre-translating binaries (potentially accelerating the
translation), and eliminating the context-switch overhead for
the translated blocks unlinked, under the new multi-cores
computing environment.
The following sections are organized as follows. First, we
introduce the resourceable and retargetable binary translator
system CrossBit in section 2. CrossBit is designed to handle
multi-guests-to-multi-hosts platforms binary translation for a
virtualized execution environment. Some formula-based
description of DBT performance will be introduced then.
Section 3 will introduce the multi-threaded execution engine
(MTEE) for CrossBit, both the architecture and implement.
Section 4 will show the experimental results of the MTEE,
and give the analysis consequently. Some related works are
showed in section 5. Finally, we will come to the conclusion
in section 6.
II. DBT CROSSBIT
A. Architecture
946
CrossBit is a resourceable and retargetable dynamic binary
translation system implemented by Shanghai Jiao Tong
University. It’s a process virtual machine developed mainly to
provide the platform independent computing service for a new
virtualized execution environment. Until recently, it has fully
or partially supported guest platforms including simplescalar,
IA32, MIPS, and has fully supported the IA32 host platform.
Another RISC instruction sets platform host is on the plan.
For platform adaptability, CrossBit creates the intermediate
representation named intermediate instruction (II) layer,
which is used to unify the representation of various sources
and target instruction sets. It mainly functions in quick adding
guest/host platforms for the CrossBit designers. However,
unlike the typical machine adaptive DBT systems, CrossBit
doesn’t generate the translator automatically. The binary
interpreting from the guest to II, and the translating from II to
the host, are all hand-written in the object-oriented language.
Programmers may take the infrastructural interfaces of
CrossBit translation module and reuse the others together with
overall system mechanism. The obvious advantage of this
infrastructure is that it provides CrossBit with direct II quality
control, which is much harder to complete in above systems.
And with intermediate representation, CrossBit can unify the
semanteme of guest platforms, and port existed optimization
from compilers to the II.
Figure 1 CrossBit Architecture
Figure 1 quoted here illustrates the architecture of DBT
CrossBit. There are totally six major components: the
bootstrapper, the translation module, the TCache, the memory
manager, the syscall handler, and the runtime profiler.
The bootstrapper is responsible for analyzing the guest
executable and loading its code and data into the physical
memory space called the guest’s memory image. The
identification of the executables, the mapping of every
executable section, the loading of runtime code, and some
dynamic linkage libraries issue, are dealt with by the
bootstrapper. After the initialization, the engine transfers the
control to the dispatcher. The dispatcher is an abstract
existence which represents the control dispatching of the
engine. It firstly transfers the control to the look-up of the
hash table. The look-up operation verifies the existence of
certain translated code block in the TCache, which is the
manager of code cache limited in size. If successful, this
operation returns the translated code block’s entry address for
executing. The dispatcher then performs context-switch
operations before and after the block execution is taken. The
execution time may vary according to the linking rate (explain
later) of blocks. Finally the dispatcher regains the control and
continues the look-up operation of the next round.
If the block is not cached, the engine calls the translation
module to work. This may happen when the required block is
not in or evicted out by the TCache. As figure 1 shows, the II
layer separates the translation process into two phases:
interpreting and translating, both of which are time-consuming.
The interpreting phase performs the binary decoding and the
binary transformation to II operations. And the translating
phase performs the register allocation, the binary encoding,
and the binary transformation to host operations. Moreover, to
get more effective translated code, some II filters may be
utilized for optimization. The DBT system always has a great
miss penalty. To be an adaptable DBT system, the miss
penalty of CrossBit is even higher. After the translated block
is generated, the engine executes it as usual.
CrossBit is a process virtual machine system and have to
deal with all system calls (syscall) provided by underlying
operating systems. This is handled by the syscall handler
module and triggered by the dispatcher. By now CrossBit can
translate binaries between different hardware architectures but
only deal with the Linux operating system. So the syscall
handler can transfer most of the POSIX syscalls directly to the
underlying system services. In spite of that some special APIs
related to processes and threads should be treated specially.
Another module called the profiler gathers all necessary
information at run time. The information profiled may be
utilized for determining hot path and thus guiding the
generation of superblocks. It also provides CrossBit with
sufficient information for other instrumentation work. To
advance the optimization and extending features, the profiling
module leaves the facility to adaptive requirements.
B. CrossBit Performance
Not considering the initialization expenditure, we’ve found
by experimentation that there are five major stages affecting
the overall time of CrossBit system:
• Look-up stage. This stage queries if the translated code
block resides in the TCache. If the cache hits, it returns
the block entry address.
• Context-switch stage. When the block entry is obtained,
either by querying hash table or by a code block
generation process, the dispatcher would switch control
to the translated code. After the execution, there would
be a control switching back.
• Execution stage. It is the native execution of the
translated code blocks. The better quality of translation
algorithm applies, the less time it would take.
947
• Translation stage. The first phase is translation. And the
second phase is translation.
• Linking stage. It does fragment chaining for the
translated code blocks.
As mentioned above, the DBT CrossBit has an even higher
miss penalty than common translators do. It implies that the
Translation stage is much slower than the others. Suppose the
DBT system only generates the basic block without trace
optimization, the overall DBT running time (Tsys) could be
considered as
Tsys = Nblock * Tblock (1)
Nblock is the number of blocks treated. Its value equals the
time of look-up operations. It is determined by the code
inflation rate, the cache size, the replacement
strategy/algorithm of TCache. The smaller inflation rate, the
bigger cache size would certainly benefit the DBT at running
time.
Tblock is the per-block time consumption. It can be
concluded as the formula bellow:
Tblock = Texecute +
Runlink * ( Tlookup + Tcontext-switch ) +
Rmiss * (Tinterpret + Ttranslate + Treplace + Tlink) (2)
The Runlink parameter stands for the percentage of the
translated blocks unlinked. It’s complementary to the linking
rate (Rlink) which is composed of two categories sorted by the
blocks’ exit type. Commonly, they are of the direct
control-transfer type, and the indirect control-transfer type.
The former may be a constant at running time. But the linking
rate is not. It is affected by the possibility of the indirect
control-transfer linking failures. A relatively stable linking
rate can be reached but is brought down when the TCache
system evicts some translated blocks.
The Rmiss parameter represents the miss rate of the TCache
system. It’s commonly determined by the cache size, the
binary inflation rate, and the replacement strategy. The
foremost factor is the cache size. Commonly, if the size of the
text section of the guest platform (guest binaries’ size)
multiplying the binaries’ inflation rate of the DBT system
doesn’t exceed the size of TCache, or not much too larger than
it, the miss rate is low and consequently leads to a good
system performance. Otherwise, replacement happens
frequently.
Basically, if the TCache is efficient and large enough to
hold all translated blocks, the TCache wouldn’t miss. The
total per-block processing time (Ttotal) is:
Tblock = Texecute + Runlink * ( Tlookup + Tcontext-switch ) (3)
The per-block execution time (Texecute) means the per-block
execution time of the native binaries wrapped in the translated
blocks. The per-block hashmap look-up time (Tlookup) together
with the per-block context switching time (Tcontext-switch),
multiplied by the unlinked rate (Runlink), comes as the penalty
for the blocks-unlinked condition. We call it the unlinked
penalty (Punlink):
Punlink = Tlookup + Tcontext-switch
However, without the replacement of TCache, translated
blocks may be well linked. As a result, the DBT system will
easily reach a steady-state processing status, in which the
linking penalty is minor, and Texecute is dominate to pre-block
processing time and even the whole system processing time.
When the TCache system misses, there are two kinds of
miss penalty (Pmiss): per-block translating time (Ttranslate), and
per-block linking time (Tlink).
Pmiss = Ttranslate + Tlink
The replacement doesn’t bring about miss penalty only, but
also brings up the unlinked rate as mentioned above. What’s
more, the number of blocks treated also rises. In such a
condition, the whole system processing time is not certain but
determined by the Rmiss. The Per-block consumption is
Tblock = Texecute + Runlink * Punlink + Rmiss * Pmiss
And the system running time is
Tsys = Nblock * (Texecute + Runlink * Punlink + Rmiss * Pmiss)
Formula 7 shows all the factors. Generally, if the Rmiss is
low enough, the whole system processing time is still
dominated by the Texecute. However, when it grows up, the
Runlink grows too. And the system execution time will not be
predominated by a single factor. Any stages may harm or
benefit the Tsys. At last, when the Rmiss reaches up to a certain
level, miss penalty will be the dominator.
Although the optimization on the Texecute is welcome in
most of the cases, any optimization on any of the stages
mentioned above is also welcome because they may all be the
candidates of the system bottleneck as the execution
environment changes.
III. MULTIPLE-THREAD EXECUTION ENGINE
A. Goals and mechanism
The design of new execution engine aims at reducing the
RT overhead. And in the last section, we have discussed the
factors affecting DBT performance. From Formula 6, we
come into the conclusion, the RT overhead arises when:
• Cache misses
• Blocks are unlinked
Either reducing the Runlink, Rmiss, Punlink, or Pmiss will benefit
the system. Therefore, the goal of the new engine design is to
reduce Punlink and Pmiss overhead. More accurately, MTEE tries
to reduce the Ttranslate, and Tcontext-switch overhead.
Unfortunately, there is one thing inevitable for DBT
running upon one a single processor: the RT and the TC have
to share the native registers which causes the register context-
switch overhead. Under certain condition, the context-switch
(4) overhead could still be the foremost factor affecting the DBT
system.
One suggestion is that the RT and TC share the target
machine registers under the control of some static or
dynamic/monitoring mechanism. However, for the DBT
developers, they handle only the registers’ usage of translated
code, which is determined at the translation phase (Mostly
done by the register allocation algorithms). But the register
context of RT is determined by the compiler ahead (The
native compiler which builds DBT) of time. It is almost
impracticable or inefficient to make them co-workers because
(5) the RT code is always built prior to the TC, and is changing
by versions if the developer doesn’t make any modification to
the local compilers.
Nevertheless, as the processor technology evolving into the
multi-cores age, there is another possibility to decouple the
RT and TC executions. The simple concept is to make the RT
and TC execution apart by threads. The RT and the TC can
run up different threads. And the threads may be then mapped
(6) into different processor cores on the fly. The obvious
advantage is that either the RT or the TC has its own register
context. Consequently, the elimination of the context
switching overhead achieves.
(7) Except for context switching elimination, reducing the
translation time of DBT system is also one goal for MTEE
design. As mentioned in the previous section, the long-time
translation phase may greatly prolong the total running time of
DBT system if the frequent replacements from TCache occur.
This is not occasional since there are many memory-limited
embedded processors planning to have multi-cores. What’s
more, some DBT implementations involving hardware
TCache support also have to deal with probably frequent
TCache replacement. Therefore, MTEE proposes to
implement the multiple threads translation, also by making
use of the multi-cores’ power, to accelerate translation phase.
The simple implementation is that the RT issues several
translations at one time. Every translation translates the source
code by blocks and commits the result out of order. If the
prediction of translation is always correct, the TC can get
more code to execute and have less time waiting for the long
time translation.
The coming section will introduce the implement of above
mechanism in MTEE.
B. Architecture
948

Figure 2 Multi-Threaded Execution Engine of CrossBit
Figure 2 is the architecture of the MTEE of CrossBit.
According to the principle of decoupling RT and TC
executions, the DBT CrossBit is decomposed into two parts:
translation and execution, which are taken by the
TranslationThread and the ExecutionThread. Here, a new
component called the BranchTree is added. It is the controller
of dispatching tasks to the TranslationThreads.
The engine starts to bootstrapper and then ramifies into
threads. The TransaltionThreads perform the overall
translation, including translating source binaries, wrapping
translated code into blocks and committing them to the
TCache. There are several TranslationThreads working
parallel. The BranchTree is the controller of threads’ work
dispatching. Every TranslationThread asks the BranchTree for
a Source PC address, from which the entry address translation
starts. At the end of each translation, every TranslationThread
commits a translated code block to the TCache. As mentioned
above, all the commitments are out of order. The blocks
committed could either be the block TranslationThread waits
for or the candidates for later TC executions. And then the
TranslationThread would query the BranchTree for next
translation. Definitely there is some mechanism inside the
branch to make the work of TranslationThread valuable. This
would be introduced later.
Meanwhile, the ExecutionThread is initialized and get to
work. However, it is a much easier work to look up the
translated code blocks from TCache and perform the TC
executing circularly.
Figure 3 Data flow of TranslationThread and ExecutionThread
Here Figure 3 shows the data that flow from the
TranslationThread to the ExecutionThread, and also the data
backwards. The ExecutionThread should provide the next
Source PC value as a notification to the BranchTree. The
949
BranchTree can then be adapted to this change and quickly
dispatch tasks to TranslationThreads, and finally fulfill the
requirement of ExecutionThread.
The translation module is expected to have a higher
throughput than before. While the normal DBT system fills
the TCache with one translated code block per time, the
MTEE fills more according to the number of
TranslationThreads. However, the number of threads should
never exceed the number of processor cores. Or else, the
performance is handicapped rather than be increased.
C. The BranchTree
The BranchTree is the key data structure to enable the
parallel translation and the RT & TC decomposition. In
MTEE, the BranchTree is the description of control flow
ignoring any loop conditions, and is organized as a binary tree.
The BranchTree has follow features:
• Every tree node represents a basic block, and tagged
with the block entry address
• The root of BranchTree represents the block last being
executed.
• The daughter nodes are the exits (destine address of
branching) of this block.
Figure 4 is one example of BranchTree.
Figure 4 The BranchTree
Each block has a token to show if it is
processed/processing/available. When there is a request from
TranslationThread, it selects the one most valuable and
available node from the BranchTree for next translation. The
selection algorithm determines the accuracy of prediction
(branch prediction of instructions accordingly). In the current
version, MTEE implements a simple selection algorithm
based on tree structure only. However, the evaluation results
will later show the defect it brings.
And whenever the ExecutionThread finishes a block
execution, it will update the global shared Source PC variable.
Then whenever the TranslationThread queries for new task, it
may find out the dismatch between the BranchTree root and
the global shared variable. Then the TranslationThread may
update the BranchTree data structure according to the change.
This mechanism ensures that the TranslationThread never
delays in responding to the real requirement from the
ExecutionThread. What’s more, it limits the synchronization
overhead.
D. Lock-free R/W operations
A fact worth noticing is that the synchronization overhead
between the TranslationThread and the ExecutionThread
would be high. There is no problem that any access of shared
modules (TCache, BranchTree, etc) should be mutually
exclusive. However, this problem is mostly caused by the
frequent TCache accesses from the ExecutionThread. It is
reasonable to lock any operation into the TCache. However, in
this condition locking could be quite expensive. By evaluation,
we found that any additional code added to the look-up
operations may result in multiplication of actual running time.
TABLE 1．OPERATIONS ON TCACHE
TCache operator Operations Operation type
TranslationThread Commit block Write
ExecutionThread Lookup block Read
From table 1, the TCache operations may be of two kinds:
write (TranslationThreads commit blocks) and read
(ExecutionThread looks up block). Whenever the
ExecutionThread looking-up fails, it may sleep until a new
block reaches. Then it may be woke up and perform the
look-up operation again. The look-up is a kind of read
operation to TCache, and it is estimated that the failure of read
may be harmless even when performing without locks.
If a TranslationThread tries to commit a block into TCache
which the ExecutionThread currently requires, without
locking but performing the look-up operation directly, it may
fail and the ExecutionThread may have to sleep then. But after
a short while, there is another commitment from a
TranslationThread that wakes up the ExecutionThread. The
latter will perform another look-up and finally get the block it
required before. As long as the TranslationThreads do not stop,
the failure of look-up may never harm the MTEE.
Consequently, it is a better solution to free such locks
between read and write to the TCache. However, the mutually
exclusive operations must be maintained between writes to
avoid mistakes.
Same mechanism is also applied to the “next Source PC”
variable to release the synchronization overhead. However,
the synchronized writes to TCache are necessary even if the
commitments of blocks are out of order.
E. Context-switch elimination
When ramified into threads, the context-switch is not
necessary for the DBT system any more. The TC may have its
own register context, for there are more physical register
groups to use. On some light weight process (LWP) operating
system implementation, the RT and TC could be properly
mapped to different physical cores and hardly with any
in-process interference. However, the MTEE implement
doesn’t completely make the TC register context TC’s. As
figure 2 shows, the Executionthread still involves some shared
context, including the shared variables such as BranchTree,
TCache, etc. When the optimization options are selected by
the native compilers, shared variables may also be compiled
and optimized into registers. This may lead to unpredictable
runtime behaviors of ExecutionThread.
950
However, with clear definition of threads’ categories, the
shared variables inside the ExecutionThread are under control.
In fact, all the shared variables may be protected by the
compiler-supported keyword (like “volatile” in C++) which
makes sure they won’t be optimized into registers. And the
protected variables won’t occupy the registers required by the
TC. In comparison with the register context in conventional
CrossBit engine, the shared variables are less in quantity. The
DBT programmer can protect them all easily. Moreover, the
DBT version changes do not affect the correctness either.
IV. EVALUATIONS
The preliminary version of the MTEE of DBT CrossBit has
been completed. The experiments were taken on the Intel Core
2 Duo host platform with the Fedora Core 6 Linux OS. The
experimental guest platform of CrossBit is SimpleScalar. The
benchmark programs are some selections from the SPEC CPU
2000. Both direct block linking and indirect block linking are
disabled in following tests. And the TranslationThread is limit
to one thread.
The first evaluation is the performance comparison between
CrossBit MTEE and CrossBit conventional engine. Figure 5
shows that MTEE leads ahead in running program mcf and
gzip, about 30% at best. However, the MTEE is much slower
than the conventional engine in running the program gcc. This
is because the MTEE miss rate is much higher in running gcc
than other programs. And it brings up the overhead of the
useless blocks generation. Here useless blocks are the block
generated by the TranslationThread, but not required by the
ExecutionThread.
Figure 5 Performance Evaluation of MTEE
Figure 6 shows how the cache size affects MTEE
performance. The statistic data is gathered when running spec
program mcf. Generally, when the cache size is smaller, the
chance of replacement arises, and the miss rate of MTEE
grows higher. But until recent release, the MTEE have much
impact on cache than conventional engine. It is because the
BranchTree selection algorithm is still based on the
BranchTree structure. The branch prediction is not accurate
enough and leads to increasingly useless blocks generation as
the cache replacements happen.

Figure 6 Cache size and performance relationship of MTEE
And the Figure 7 quoted illustrated the useless blocks
generation of MTEE in running program mcf. The useless
blocks are generated every time the TCache misses. Although
the generation of block only takes the TranslationThread time,
there is no guarantee from the operating system that the
TranslationThread works always and never exhaust its
timeslice. Since the translating overhead is still high, the
useless block generation could be harmful to whole system
time. From the figure, the black curve which represents the
percentage of effective block (That is used by the
ExecutionThread) in cache, never drops, but the absolute
useless blocks arises when the TCache size becomes smaller.
Consequently, the translation harms the cache as Figure 6
shows.
Figure 7 MTEE useless block generation
With context-switch elimination, the MTEE has some
superiority over the conventional CrossBit execution engine.
However, the multiple threads translation is not enabled
because the experiment platform just has two physical cores.
However, the branch prediction mechanism of MTEE is still
ugly and results in too much useless block generations. And
according to current operating system implementation
threading support, we consider the BranchTree selection
algorithm as the key point to better performance. We are
expecting the MTEE to be more powerful after further
optimizations.
951
V. RELATED WORDS
There are several existed machine-adaptable DBT systems,
such as the UQDBT [8] dynamic translator, which is based on
the famous static UQBT [7] framework. It uses specifications
to specify the guest/host architectures at various levels of
abstraction. And by going through several intermediate
representations, it completes binary translation dynamically.
However, the low performance and great translation overhead
of dynamic translation on machine-adaptable DBT systems
aroused concerns. So bintrans[9] project takes specification
but without intermediate representation to accelerate the
translation process. Later system like walkabout [10] makes
further study on dynamic translation for machine-adaptable
DNT. But aside of machine adaptability, it also constructed
binary rewriting tool for various purposes. The Strata [11]
program provides the binary translation framework, which
also have partly free the developer from full work of
constructing DBT system. Strata has full implemented the
basic optimization and its evaluation shows the effectiveness
of these approach [16].
To make DBTs practical to use, much research has been
performed, especially by the dynamic optimizers. One of the
most famous dynamic optimization systems is Dynamo [12].
Aside from the approaches like fragment chaining, hot trace
identification and trace/superblock formation, Dynamo
implements many compiler optimizations dynamically. Its
advatage is then transparent working which makes Dynamo
easy to be bundled with operation system. Dynamo’s IA32
derivative DynamoRIO [13] also reaches to a better
performance than native execution. Yet it is mentioned in the
literature that when implementing Dynamo on HP PA8000
system, the designer prefers interpretation to translation and
block caching, just because of eliminating the overhead of a
large number of registers context switches. So we presume the
performance enhancement of context-switch overhead
elimination will be more obvious in register-rich architectures.
And the Mojo [14] developed by Microsoft Research, is the
dynamic optimizer works on IA32 & Windows architecture,
which gives a good example to handling multiple threads
applications.
VI. CONCLUSION AND FUTURE WORK
Conventional optimization method of Binary Translation
makes more effort to reorganize or reduce the size of the
translated binaries. However, binary translation is still
sensitive to condition changes. The MTEE provides another
way to optimize the DBT systems which employs the multiple
processor power. On one hand, it aims at providing the
translated code an owned register context. On the other hand,
it aims at building the software pipeline stages for the DBT
system. However, software threads do not work as hardware
components do. They highly rely on the operating system
implementation. And the conventional operating system
makes greater effort to enable concurrency rather than parallel
execution. It gives the multiple threads program developer
less control of multi-cores power. The DBT upon multi-core
still has many barriers to overcome.
Further work of the MTEE involves the better branch
prediction mechanism and its implementation, the
optimization on thread programming. And as the processor
cores grow, we expect to have experiments on these new
platforms, and finally power the DBTs by parallelism.
ACKNOWLEGEMENT
This work was supported by the National Nature Science
Foundation of China under Grant No. 60773093, the National
Grand Fundamental Research 973 Program of China under
Grunt No.2007CB316506, the 863 Research and Development
Program of China under Grunt No. 2006AA01Z169.

REFERENCES
[1] J.E. Smith, and R. Nair, Virtual Machines: Versatile Platforms for
Systems and Process, Morgan Kaufman, 2005.
[2] Y, Bao. “Building Process Virtual Machine via Dynamic Binary
Translation.” Master thesis of School of Software, Shanghai Jiao Tong
University, January 2007.
[3] A. Chernoff, M. Herdeg, R. Hookway, C. Reeve, N. Rubin, T. Tye, S.
B. Yadavalli, and J. Yates, “FX!32: A profile-directed binary
translator”, IEEE Micro, April 1998.
[4] B. Leonid; T. Devor, O. Etzion, S. Goldenberg, A. Skaletsky, Y. Wang
and Y. Zemach. “IA-32 Execution Layer: a two-phase dynamic
translator designed to support IA-32 applications on Itanium®-based
systems”, MICRO-36, 2003.
[5] J. Dehnert, B. K. Grant, J. P. Banning, R. Johnson, T. Kistler, A.
Klaiber, and J. Mattson, “The Transmeta Code Morphing Software:
Using speculation, recovery, and adaptive retranslation to address
real-life challenges”, CGO-2003, Pages 15-24, March 2003.
[6] Zheng, C. Thompson, C. PA-RISC to IA-64: transparent execution, no
recompilation. IEEE Computer Society, 33(3): 47-52, March 2000.
[7] C. Cifuentes and M. Van Emmerik, “UQBT: Adaptable binary
translation at low cost.” Computer, 33(3):60-66, March 2000.
[8] D. Ung, C. Cifuentes, “Machine-adaptable dynamic binary translation”,
ACM SIGPLAN Workshop on Dynamic and Adaptive Compilation and
Optimization, Pages: 30-40, January 2000.
[9] M. Probst, “Fast Machine-Adaptable Dynamic Binary Translation”,
Proceedings of the Workshop on Binary Translation, 2001.
[10] C. Cifuentes, B. Lewis, and D. Ung, “Walkabout —A retargetable
dynamic binary translation framework”, Workshop on Binary
Translation, January 2002.
[11] K. Scott, and J. Davidson, “Strata: A software dynamic translation
infrastructure”, Proceedings of the IEEE 2001 Workshop on Binary
Translation, 2001.
[12] V. Bala, E. Duesterwald, and S. Banerjia, “Dynamo: A transparent
dynamic optimization system”, Proceedings of the ACM SIGPLAN ’00
Conference on Programming Language Design and Implementation,
June 2000
[13] D. Bruening, T. Garnett, and S. Amarasinghe, “An infrastructure for
adaptive dynamic optimization”, CGO-2003, Pages: 265-275, March
2003.
[14] W. K. Chen, S. Lerner, R. Chaiken, and D.M. Gillies, “Mojo: A
dynamic optimization system”, Proceedings of 3rd ACM Workshop on
Feedback-Directed and Dynamic Optimization, 2000.
[15] U. Hölzle, L. Bak, S. Grarup, R. Griesemer, and S. Mitrovic, “Java on
steroids: Sun's high-performance Java implementation”, Proceedings of
HotChip IX, 1997.
[16] K. Scott, and J. Davidson, Strata: A software dynamic translation
infrastructure, Proceedings of the IEEE 2001 Workshop on Binary
Translation, 2001.
[17] K. Scott, N. Kumar, B.R. Childers, J.W. Davidson, M.L. Soffa,
“Overhead Reduction Techniques for Software Dynamic Translation”,
Proceedings of 18th International Parallel and Distributed Processing
Symposium, 2004, April 2004.

952