DMCA
Hardware Transactional Memory Support for Lightweight Dynamic Language Evolution
Cached
Download Links
| Citations: | 3 - 1 self |
BibTeX
@MISC{Riley_hardwaretransactional,
author = {Nicholas Riley},
title = {Hardware Transactional Memory Support for Lightweight Dynamic Language Evolution},
year = {}
}
Share
 |
 |
 |
 |
||
OpenURL
Abstract
Lightweight dynamic language runtimes have become popular in part because they simply integrate with a wide range of native code libraries and embedding applications. However, further development of these runtimes in the areas of concurrency, efficiency and safety is impeded by the desire to maintain their native code interfaces, even at a source level. Native extension modules ’ lack of thread safety is a significant barrier to dynamic languages ’ effective deployment on current and future multicore and multiprocessor systems. We propose the use of hardware transactional memory (HTM) to aid runtimes in evolving more capable and robust execution models while maintaining native code compatibility. To explore these ideas, we constructed a full-system simulation infrastructure consisting of an HTM implementation, modified Linux kernel and Python interpreter. Python includes thread constructs, but its primary implementation is not architected to support their parallel execution. With small changes, a runtime can be made HTMaware to enable parallel execution of Python code and extension modules. We exploit the semantics of Python execution to evaluate individual bytecodes atomically by default, using nested transactions to emulate programmer-specified locking constructs where possible in existing threaded code. We eliminate common transactional conflicts and defer I/O within transactions to make parallel Python execution both possible and efficient. Transactions also provide safety for foreign function invocations. We characterize several small Python applications executing on our infrastructure. 1.
Keyphrases
lightweight dynamic language evolution hardware transactional memory support parallel execution primary implementation native code compatibility foreign function invocation python execution native extension module lack htm implementation wide range linux kernel source level robust execution model small change language effective deployment full-system simulation infrastructure parallel python execution thread construct thread safety extension module common transactional conflict nested transaction several small python application threaded code multiprocessor system native code library programmer-specified locking construct individual bytecodes python code hardware transactional memory future multicore significant barrier python interpreter lightweight dynamic language runtimes native code interface
