Interpreter Register Autolocalisation: ...
Document type :
Communication dans un congrès avec actes
Title :
Interpreter Register Autolocalisation: Improving the performance of efficient interpreters
Author(s) :
Polito, Guillermo [Auteur]
Analyses and Languages Constructs for Object-Oriented Application Evolution [RMOD]
Palumbo, Nahuel [Auteur]
Analyses and Languages Constructs for Object-Oriented Application Evolution [RMOD]
Tesone, Pablo [Auteur]
Pharo consortium
Inria Lille - Nord Europe
Labsari, Soufyane [Auteur]
Analyses and Languages Constructs for Object-Oriented Application Evolution [RMOD]
Ducasse, Stephane [Auteur]
Analyses and Languages Constructs for Object-Oriented Application Evolution [RMOD]
Analyses and Languages Constructs for Object-Oriented Application Evolution [RMOD]
Palumbo, Nahuel [Auteur]
Analyses and Languages Constructs for Object-Oriented Application Evolution [RMOD]
Tesone, Pablo [Auteur]
Pharo consortium
Inria Lille - Nord Europe
Labsari, Soufyane [Auteur]
Analyses and Languages Constructs for Object-Oriented Application Evolution [RMOD]
Ducasse, Stephane [Auteur]

Analyses and Languages Constructs for Object-Oriented Application Evolution [RMOD]
Conference title :
MoreVMs 2022
City :
Porto
Country :
Portugal
Start date of the conference :
2022-03-21
English keyword(s) :
virtual machine
interpreter
optimisation
code transformation
interpreter
optimisation
code transformation
HAL domain(s) :
Informatique [cs]/Langage de programmation [cs.PL]
English abstract : [en]
Language interpreters are generally slower than (JIT) compiled implementations because they trade off simplicity for performance and portability. However, they are still an important part of modern Virtual Machines (VMs) ...
Show more >Language interpreters are generally slower than (JIT) compiled implementations because they trade off simplicity for performance and portability. However, they are still an important part of modern Virtual Machines (VMs) as part of mixed-mode execution schema. The reasons behind their importance are many. On the one hand, not all code gets hot and deserves to be optimized by JIT compilers. Examples of cold code are tests, command-line applications, and scripts. On the other hand, compilers are more difficult to write and maintain, thus interpreters are an attractive solution because of their simplicity and portability. In the context of this paper, we will center on bytecode interpreters. Interpreter performance has been a hot topic for a long time, where several solutions have been proposed with different ranges of complexity and portability. On the one hand, some work proposes to optimize language-specific features in interpreters such as type dispatches using static type predictions, quickening [3] or type specializations [18]. On the other hand, many solutions focus on improving general interpreter behavior by minimizing branch miss-predictions of interpreter dispatches and stack caching. Solutions to branch mis-predictions propose variants of code threading [1, 4, 6, 7, 10] and improving it further with selective inlining [14]. Some solutions aim for minimizing branch miss-predictions by modifying the intermediate code (e.g., bytecode) design with super-instructions [15] and register-based instructions [9, 16]. Stack caching [5] proposes to optimize the access of operands by caching the top of the stack. interpreter registers are also related to stack caching: interpreter variables that are critical to the efficient execution of the interpreter loop. Examples of such variables are the instruction pointer (IP), the stack pointer (SP), and the frame pointer (FP). Interpreter registers put pressure on the overall design and implementation of the interpreter: Req1: Value access outside the interpreter loop. VM routines outside of the interpreter loop may require access to interpreter registers. For example, this is the case of garbage collectors that need to traverse the stack to find root objects, routines that unwind or reify the stack, or give access to stack values to native methods. Req2: Efficiency. Interpreter registers are used on each instruction to manipulate the instruction stream and the stack. Under-efficient implementations have negative impacts on performance.Show less >
Show more >Language interpreters are generally slower than (JIT) compiled implementations because they trade off simplicity for performance and portability. However, they are still an important part of modern Virtual Machines (VMs) as part of mixed-mode execution schema. The reasons behind their importance are many. On the one hand, not all code gets hot and deserves to be optimized by JIT compilers. Examples of cold code are tests, command-line applications, and scripts. On the other hand, compilers are more difficult to write and maintain, thus interpreters are an attractive solution because of their simplicity and portability. In the context of this paper, we will center on bytecode interpreters. Interpreter performance has been a hot topic for a long time, where several solutions have been proposed with different ranges of complexity and portability. On the one hand, some work proposes to optimize language-specific features in interpreters such as type dispatches using static type predictions, quickening [3] or type specializations [18]. On the other hand, many solutions focus on improving general interpreter behavior by minimizing branch miss-predictions of interpreter dispatches and stack caching. Solutions to branch mis-predictions propose variants of code threading [1, 4, 6, 7, 10] and improving it further with selective inlining [14]. Some solutions aim for minimizing branch miss-predictions by modifying the intermediate code (e.g., bytecode) design with super-instructions [15] and register-based instructions [9, 16]. Stack caching [5] proposes to optimize the access of operands by caching the top of the stack. interpreter registers are also related to stack caching: interpreter variables that are critical to the efficient execution of the interpreter loop. Examples of such variables are the instruction pointer (IP), the stack pointer (SP), and the frame pointer (FP). Interpreter registers put pressure on the overall design and implementation of the interpreter: Req1: Value access outside the interpreter loop. VM routines outside of the interpreter loop may require access to interpreter registers. For example, this is the case of garbage collectors that need to traverse the stack to find root objects, routines that unwind or reify the stack, or give access to stack values to native methods. Req2: Efficiency. Interpreter registers are used on each instruction to manipulate the instruction stream and the stack. Under-efficient implementations have negative impacts on performance.Show less >
Language :
Anglais
Peer reviewed article :
Oui
Audience :
Internationale
Popular science :
Non
Collections :
Source :
Files
- https://hal.inria.fr/hal-03594766/document
- Open access
- Access the document
- https://hal.inria.fr/hal-03594766/document
- Open access
- Access the document
- https://hal.inria.fr/hal-03594766/document
- Open access
- Access the document
- document
- Open access
- Access the document
- Poli22a-MoreVM22-Autolocalisation.pdf
- Open access
- Access the document