Heuristics to predict and eagerly translate code in DBTs

Dynamic Binary Translators(DBTs) have a variety of uses, like instrumentation, profiling, security, portability, etc. In order for the desired application to run with these enhanced additional features(not originally part of its design), it is to be run under the control of Dynamic Binary Translator. The application can be thought of as the guest application, to be run with in a controlled environment of the translator, which would be the host application. That way, the intended application execution flow can be enforced by the translator, thereby inducing the desired behavior in the application on the host platform(combination of Operating System and Hardware). However, there will be a run-time/execution-time overhead in the translator, when performing the additional tasks to run the guest application in a controlled fashion. This run-time overhead has been limiting the usage of DBT's on a large scale, where response times can be critical. There is often a trade-off between the benefits of using a DBT against the overall application response time. So, there is a need to research/explore ways to faster application execution through DBT's(given their large code-base). With the evolution of the multi-core and GPU hardware architectures, multilpe concurrent threads can get more work done through parallelization. A proper design of parallel applications or parallelizing parts of existing serial code, can lead to improved application run-time's through hardware architecture support. We explore the possibility of improving the performance of a DBT named DynamoRIO. The basic idea is to improve its performance by speeding-up the process of guest code translation, through multiple threads translating multiple pieces of code concurrently. In an ideal case, all the required code blocks for application execution are readily available ahead of time without any stalls. For efficient eager translation, there is also a need for heuristics to better predict the next code block to be executed. That could potentially bring down the less productive code translations at run-time. The goal is to get application speed-up through eager translation and block prediction heuristics, with execution time close to native run