Workshop VMIL 2016 – Author Index |
Contents -
Abstracts -
Authors
|
Chapman, Keith |
![]() Keith Chapman, Antony L. Hosking, and J. Eliot B. Moss (Purdue University, USA; Australian National University, Australia; Data61, Australia; University of Massachusetts at Amherst, USA) We have recently described and evaluated a research prototype system (called XJ, for transactional Java) that allows execution of Java programs extended with transactional memory (TM) abstractions (Chapman et al. 2014, 2016). The system allows mixed execution of these abstractions using both software (STM) and hardware (HTM) transactional memory. The prototype system, based on OpenJDK, suffers a number of roadblocks impeding production use, including: (i) Per-object metadata in support of manipulation of objects by transactions is inserted via bytecode rewriting at load time, in the form of a new word-sized instance field placed at the beginning of each object; (ii) The HotSpot optimizing compilers (C1 and C2) require gentle coaxing to compile both the STM and HTM versions of methods via alternating execution in a warm-up phase. Here we explore possible changes to OpenJDK that would allow for more integrated support for TM in HotSpot, as needed to support hybrid STM/HTM. These changes include encoding per-object transactional metadata in the synchronization word carried by all OpenJDK objects, and integrating more effectively with the profiling and compilation mechanisms of the HotSpot interpreter and compilers. We believe that the proposed changes are incremental, though we also expect that a deeper re-engineering would yield somewhat better ability to tune synchronization hot-paths for performance. ![]() |
|
De Roover, Coen |
![]() Maarten Vandercammen and Coen De Roover (Vrije Universiteit Brussel, Belgium) Trace-based just-in-time compilers use program analyses to optimise execution traces. These analyses are limited in scope to the parts of the program that have been traced. In this position paper, we conjecture that trace optimisations can benefit from extending the scope of their enabling analyses beyond these traces to the set of possible future execution states of the program. This by incorporating a static analysis which, however, necessarily over-approximates this set. We therefore propose to continuously refine the set of future states computed by an initial, ahead-of-time analysis using run-time information about the current execution state of the program. Additional static analyses launched at run time could further refine the information about the future of the current and all possible states. We expect that the resulting, hybrid program view of static and dynamic information may enable additional optimisations on collected traces and that these optimisations may overcome the computational overhead of keeping the view up-to-date. ![]() |
|
Gaudet, Matthew |
![]() Matthew Gaudet and Mark Stoodley (IBM, Canada) Eclipse OMR is a new open source project created by refactoring the IBM J9 Java Virtual Machine to create a set of language agnostic components for building all kinds of language runtimes. This paper reflects on the effort, the successes, and the mistakes made while refactoring more than a million lines of code on the master development branch while 8 disparate production compiler products were under active development. Refactoring large scale projects like compilers and language runtimes can be done while shipping releases, but there are certainly challenges. We offer some recommendations for other projects considering this path. ![]() |
|
Grimmer, Matthias |
![]() Manuel Rigger, Matthias Grimmer, Christian Wimmer, Thomas Würthinger, and Hanspeter Mössenböck (JKU Linz, Austria; Oracle Labs, USA; Oracle Labs, Switzerland) Although the Java platform has been used as a multi-language platform, most of the low-level languages (such as C, Fortran, and C++) cannot be executed efficiently on the JVM. We propose Sulong, a system that can execute LLVM-based languages on the JVM. By targeting LLVM IR, Sulong is able to execute C, Fortran, and other languages that can be compiled to LLVM IR. Sulong combines LLVM’s static optimizations with dynamic compilation to reach a peak performance that is near to the performance achievable with static compilers. For C benchmarks, Sulong’s peak runtime performance is on average 1.39× slower (0.79× to 2.45×) compared to the performance of executables compiled by Clang O3. For Fortran benchmarks, Sulong is 2.63× slower (1.43× to 4.96×) than the performance of executables compiled by GCC O3. This low overhead makes Sulong an alternative to Java’s native function interfaces. More importantly, it also allows other JVM language implementations to use Sulong for implementing their native interfaces. ![]() |
|
Hosking, Antony L. |
![]() Keith Chapman, Antony L. Hosking, and J. Eliot B. Moss (Purdue University, USA; Australian National University, Australia; Data61, Australia; University of Massachusetts at Amherst, USA) We have recently described and evaluated a research prototype system (called XJ, for transactional Java) that allows execution of Java programs extended with transactional memory (TM) abstractions (Chapman et al. 2014, 2016). The system allows mixed execution of these abstractions using both software (STM) and hardware (HTM) transactional memory. The prototype system, based on OpenJDK, suffers a number of roadblocks impeding production use, including: (i) Per-object metadata in support of manipulation of objects by transactions is inserted via bytecode rewriting at load time, in the form of a new word-sized instance field placed at the beginning of each object; (ii) The HotSpot optimizing compilers (C1 and C2) require gentle coaxing to compile both the STM and HTM versions of methods via alternating execution in a warm-up phase. Here we explore possible changes to OpenJDK that would allow for more integrated support for TM in HotSpot, as needed to support hybrid STM/HTM. These changes include encoding per-object transactional metadata in the synchronization word carried by all OpenJDK objects, and integrating more effectively with the profiling and compilation mechanisms of the HotSpot interpreter and compilers. We believe that the proposed changes are incremental, though we also expect that a deeper re-engineering would yield somewhat better ability to tune synchronization hot-paths for performance. ![]() |
|
Moss, J. Eliot B. |
![]() Keith Chapman, Antony L. Hosking, and J. Eliot B. Moss (Purdue University, USA; Australian National University, Australia; Data61, Australia; University of Massachusetts at Amherst, USA) We have recently described and evaluated a research prototype system (called XJ, for transactional Java) that allows execution of Java programs extended with transactional memory (TM) abstractions (Chapman et al. 2014, 2016). The system allows mixed execution of these abstractions using both software (STM) and hardware (HTM) transactional memory. The prototype system, based on OpenJDK, suffers a number of roadblocks impeding production use, including: (i) Per-object metadata in support of manipulation of objects by transactions is inserted via bytecode rewriting at load time, in the form of a new word-sized instance field placed at the beginning of each object; (ii) The HotSpot optimizing compilers (C1 and C2) require gentle coaxing to compile both the STM and HTM versions of methods via alternating execution in a warm-up phase. Here we explore possible changes to OpenJDK that would allow for more integrated support for TM in HotSpot, as needed to support hybrid STM/HTM. These changes include encoding per-object transactional metadata in the synchronization word carried by all OpenJDK objects, and integrating more effectively with the profiling and compilation mechanisms of the HotSpot interpreter and compilers. We believe that the proposed changes are incremental, though we also expect that a deeper re-engineering would yield somewhat better ability to tune synchronization hot-paths for performance. ![]() |
|
Mössenböck, Hanspeter |
![]() Manuel Rigger, Matthias Grimmer, Christian Wimmer, Thomas Würthinger, and Hanspeter Mössenböck (JKU Linz, Austria; Oracle Labs, USA; Oracle Labs, Switzerland) Although the Java platform has been used as a multi-language platform, most of the low-level languages (such as C, Fortran, and C++) cannot be executed efficiently on the JVM. We propose Sulong, a system that can execute LLVM-based languages on the JVM. By targeting LLVM IR, Sulong is able to execute C, Fortran, and other languages that can be compiled to LLVM IR. Sulong combines LLVM’s static optimizations with dynamic compilation to reach a peak performance that is near to the performance achievable with static compilers. For C benchmarks, Sulong’s peak runtime performance is on average 1.39× slower (0.79× to 2.45×) compared to the performance of executables compiled by Clang O3. For Fortran benchmarks, Sulong is 2.63× slower (1.43× to 4.96×) than the performance of executables compiled by GCC O3. This low overhead makes Sulong an alternative to Java’s native function interfaces. More importantly, it also allows other JVM language implementations to use Sulong for implementing their native interfaces. ![]() |
|
Rigger, Manuel |
![]() Manuel Rigger, Matthias Grimmer, Christian Wimmer, Thomas Würthinger, and Hanspeter Mössenböck (JKU Linz, Austria; Oracle Labs, USA; Oracle Labs, Switzerland) Although the Java platform has been used as a multi-language platform, most of the low-level languages (such as C, Fortran, and C++) cannot be executed efficiently on the JVM. We propose Sulong, a system that can execute LLVM-based languages on the JVM. By targeting LLVM IR, Sulong is able to execute C, Fortran, and other languages that can be compiled to LLVM IR. Sulong combines LLVM’s static optimizations with dynamic compilation to reach a peak performance that is near to the performance achievable with static compilers. For C benchmarks, Sulong’s peak runtime performance is on average 1.39× slower (0.79× to 2.45×) compared to the performance of executables compiled by Clang O3. For Fortran benchmarks, Sulong is 2.63× slower (1.43× to 4.96×) than the performance of executables compiled by GCC O3. This low overhead makes Sulong an alternative to Java’s native function interfaces. More importantly, it also allows other JVM language implementations to use Sulong for implementing their native interfaces. ![]() |
|
Stoodley, Mark |
![]() Matthew Gaudet and Mark Stoodley (IBM, Canada) Eclipse OMR is a new open source project created by refactoring the IBM J9 Java Virtual Machine to create a set of language agnostic components for building all kinds of language runtimes. This paper reflects on the effort, the successes, and the mistakes made while refactoring more than a million lines of code on the master development branch while 8 disparate production compiler products were under active development. Refactoring large scale projects like compilers and language runtimes can be done while shipping releases, but there are certainly challenges. We offer some recommendations for other projects considering this path. ![]() |
|
Vandercammen, Maarten |
![]() Maarten Vandercammen and Coen De Roover (Vrije Universiteit Brussel, Belgium) Trace-based just-in-time compilers use program analyses to optimise execution traces. These analyses are limited in scope to the parts of the program that have been traced. In this position paper, we conjecture that trace optimisations can benefit from extending the scope of their enabling analyses beyond these traces to the set of possible future execution states of the program. This by incorporating a static analysis which, however, necessarily over-approximates this set. We therefore propose to continuously refine the set of future states computed by an initial, ahead-of-time analysis using run-time information about the current execution state of the program. Additional static analyses launched at run time could further refine the information about the future of the current and all possible states. We expect that the resulting, hybrid program view of static and dynamic information may enable additional optimisations on collected traces and that these optimisations may overcome the computational overhead of keeping the view up-to-date. ![]() |
|
Wimmer, Christian |
![]() Manuel Rigger, Matthias Grimmer, Christian Wimmer, Thomas Würthinger, and Hanspeter Mössenböck (JKU Linz, Austria; Oracle Labs, USA; Oracle Labs, Switzerland) Although the Java platform has been used as a multi-language platform, most of the low-level languages (such as C, Fortran, and C++) cannot be executed efficiently on the JVM. We propose Sulong, a system that can execute LLVM-based languages on the JVM. By targeting LLVM IR, Sulong is able to execute C, Fortran, and other languages that can be compiled to LLVM IR. Sulong combines LLVM’s static optimizations with dynamic compilation to reach a peak performance that is near to the performance achievable with static compilers. For C benchmarks, Sulong’s peak runtime performance is on average 1.39× slower (0.79× to 2.45×) compared to the performance of executables compiled by Clang O3. For Fortran benchmarks, Sulong is 2.63× slower (1.43× to 4.96×) than the performance of executables compiled by GCC O3. This low overhead makes Sulong an alternative to Java’s native function interfaces. More importantly, it also allows other JVM language implementations to use Sulong for implementing their native interfaces. ![]() |
|
Würthinger, Thomas |
![]() Manuel Rigger, Matthias Grimmer, Christian Wimmer, Thomas Würthinger, and Hanspeter Mössenböck (JKU Linz, Austria; Oracle Labs, USA; Oracle Labs, Switzerland) Although the Java platform has been used as a multi-language platform, most of the low-level languages (such as C, Fortran, and C++) cannot be executed efficiently on the JVM. We propose Sulong, a system that can execute LLVM-based languages on the JVM. By targeting LLVM IR, Sulong is able to execute C, Fortran, and other languages that can be compiled to LLVM IR. Sulong combines LLVM’s static optimizations with dynamic compilation to reach a peak performance that is near to the performance achievable with static compilers. For C benchmarks, Sulong’s peak runtime performance is on average 1.39× slower (0.79× to 2.45×) compared to the performance of executables compiled by Clang O3. For Fortran benchmarks, Sulong is 2.63× slower (1.43× to 4.96×) than the performance of executables compiled by GCC O3. This low overhead makes Sulong an alternative to Java’s native function interfaces. More importantly, it also allows other JVM language implementations to use Sulong for implementing their native interfaces. ![]() |
12 authors
proc time: 0.82