Which problems does a multi-language virtual machine need to solve in the multicore/manycore era?

  • Authors:
  • Stefan Marr;Mattias De Wael;Michael Haupt;Theo D'Hondt

  • Affiliations:
  • Vrije Universiteit Brussel, Brussel, Belgium;Vrije Universiteit Brussel, Brussel, Belgium;Oracle Labs, Potsdam, Germany;Vrije Universiteit Brussel, Brussel, Belgium

  • Venue:
  • Proceedings of the compilation of the co-located workshops on DSM'11, TMC'11, AGERE!'11, AOOPES'11, NEAT'11, & VMIL'11
  • Year:
  • 2011

Quantified Score

Hi-index 0.00

Visualization

Abstract

While parallel programming for very regular problems has been used in the scientific community by non-computer-scientists successfully for a few decades now, concurrent programming and solving irregular problems remains hard. Furthermore, we shift from few expert system programmers mastering concurrency for a constrained set of problems to mainstream application developers being required to master concurrency for a wide variety of problems. Consequently, high-level language virtual machine (VM) research faces interesting questions. What are processor design changes that have an impact on the abstractions provided by VMs to provide platform independence? How can application programmers' diverse needs be facilitated to solve concurrent programming problems? We argue that VMs will need to be ready for a wide range of different concurrency models that allow solving concurrency problems with appropriate abstractions. Furthermore, they need to abstract from heterogeneous processor architectures, varying performance characteristics, need to account for memory access cost and inter-core communication mechanisms but should only expose the minimal useful set of notions like locality, explicit communication, and adaptable scheduling to maintain their abstracting nature. Eventually, language designers need to be enabled to guarantee properties like encapsulation, scheduling guarantees, and immutability also when an interaction between different problem-specific concurrency abstractions is required.