Threats to Validity

Completeness of Selected Subjects The main survey question was: how do

today’s VMs support parallel and concurrent programming approaches?The answer to this question is based on a set of thirteen VMs. Thus, the number is limited and the selected set may exclude VMs that provide other mechanisms and ex- pose them in other ways to the application programmer. However, since the survey covers contemporary multi-language VMs, and a number of additional VMs respected for their support for parallel and concurrent programming, it covers the VMs that are directly relevant for the goal of this dissertation. Furthermore, the selected VMs reflect common practice in VM support for con- current and parallel programming approaches, because the selection includes the most widely used VMs, as well.

Correctness and Completeness of Results With respect to the concrete sur-

vey questions of which concepts are exposed and how they are exposed, a number of threats to correctness and completeness of the results need to be considered.

General Threats to Accuracy As shown inTab. 3.1, the analysis did not in-

clude the implementations of the CLI and DisVM. Instead, the quality of their

specification is deemed sufficiently precise to answer the questions for which and how concepts are exposed accurately.

Other aspects have a stronger impact on the confidence in the results. In general, the survey is based on the specifications, language manuals, and inspection of actual implementations. While it initially included the Parrot VM16 _{as an interesting subject, it was omitted, since the mismatch between} documentation and implementation was major. It was not clear whether the documentation was outdated or visionary, or whether the understanding of the implementation was not sufficient, making a proper assessment impossi- ble. This example raises the question of how valid the results are. Most imple- mentations use customary names and make an effort to be comprehensible, which results in a high confidence in the results. However, it is not possible to eliminate the possibility that the analysis is to a lesser extent inaccurate or incomplete.

Exposure Assessment The confidence in the assessment that a given con-

cept is supported directly by a VM is high, because the VM implementations provide direct evidence that a concept is supported as primitive or as part of the the instruction set. However, a concept may have been missed. Thus, some concepts may in fact be supported by the VM directly. Completeness is thus an issue for the question of whether concepts are directly supported by a VM. This assessment could also not by verify trivially. However, this form of completeness has only little impact on the overall results, since it includes a larger number of different VMs.

Concept Completeness The confidence in the completeness of the overall

identified set of concepts that is exposed by a VM and its libraries is high, because the typically sufficiently extensive and well structured language doc- umentations enable a trivial verification for completeness.

Problematic are concepts that are solely available in the implementations and remain undocumented. One example for such a case is the relatively well know Unsafe class in Oracle’s JVM implementation.17 _{Other similarly} private APIs might have been missed. Arguably, such concepts are not meant to be used by programmers targeting the VM, and therefore do not need to be considered as concepts that are offered by the VM. Instead, these concepts are

16_{http://www.parrot.org/}

17_{http://hg.openjdk.java.net/jdk7/jdk7/jdk/log/tip/src/share/classes/sun/misc/U}

considered internal basic building blocks outside of the scope of this survey, and thus do not have an influence on our results.

3.1.3. Conclusion

Summary This survey investigated the state of the art in VM support for

concurrent and parallel programming. It examined thirteen VMs, including contemporary multi-language VMs and a number of VMs selected for their support for concurrent and parallel programming. The analysis identified for each VM the concepts it exposes and whether it exposes them in terms of implicit semantics, as part of the VM’s instruction set architecture, in terms of primitives, or merely as part of the standard libraries. The main insight is that the analyzed VMs only support one or two categories of concepts. Fur- thermore, they consistently relegate support for parallel programming to the standard library without providing explicit support for optimization.

Concept Exposure In answering the question of how concepts are exposed,

the survey shows that very general concepts such as shared memory, mem- ory models, and global interpreter lock semantics are realized by a combina- tion of mechanisms in the VM, which were categorized as implicit semantics

(cf. Sec. 3.1.1.1). Typically, they have an impact on most parts of a VM, be-

cause they require guarantees from a wide range of VM subsystems. More restricted, and often performance sensitive concepts are exposed as part of the overall instruction set architecture. Examples are monitors, synchronized methods, volatile variables, and in some cases also high-level concepts like channels, message sends, message receives, and threads or processes.

Primitives are used for a wide range of concepts. Design decisions differ between VMs, thus some concepts are supported either in the instruction set or as primitives, e. g., locks, channels, and threads, but also concepts like atomic operations, and condition variables. Other high-level concurrency con- cepts such as concurrent data structures are provided as libraries. With the definitions of concurrent and parallel programming of Sec. 2.3 in mind, the conclusion is that none of the concepts that are provided with implicit seman- tics, ISA support, or primitives is directly related to parallel programming. Instead, all the identified parallel programming concepts have been realized in the form of libraries.

Only limited support for concurrent and parallel programming. Since sup-

gorized as providing abstractions for Data Parallelism. However, roughly half of the VMs provide abstractions around Threads and Locks. Three provide ab- stractions for Communicating Threads, and five provide abstractions for Com- municating Isolates. Only three of the VMs provide abstractions for two of these categorizes. Therefore, most of the contemporary VMs concentrate on a single model for concurrent programming.

To conclude, it is uncommon to support multiple concurrent or parallel programming concepts. This is not surprising, since most VMs are built for a single language. Furthermore, support for parallel programming is relegated to libraries, and none of the examined VMs provides direct support for it.

Seeing the current state of the art and the design choice of supporting only a small number of specific concepts in VMs, it remains open how multiple