Write a Blog >>
SPLASH 2017
Sun 22 - Fri 27 October 2017 Vancouver, Canada
Wed 25 Oct 2017 10:30 - 10:52 at Regency C - Performance Chair(s): Kathryn S McKinley

A memory consistency model (or simply memory model) defines the possible values that a shared-memory read may return in a multithreaded programming language. Choosing a memory model involves an inherent performance-programmability tradeoff. The Java language has adopted a relaxed (or weak) memory model that is designed to admit most traditional compiler optimizations and obviate the need for hardware fences on most shared-memory accesses. The downside, however, is that programmers are exposed to a complex and unintuitive semantics and must carefully declare certain variables as volatile in order to enforce program orderings that are necessary for proper behavior.

This paper proposes a simpler and stronger memory model for Java through a conceptually small change: every variable has volatile semantics by default, but the language allows a programmer to tag certain variables, methods, or classes as relaxed and provides the current Java semantics for these portions of code. This volatile-by-default semantics provides sequential consistency (SC) for all programs by default. At the same time, expert programmers retain the freedom to build performance-critical libraries that violate the SC semantics.

At the outset, it is unclear if the volatile-by-default semantics is practical for Java, given the cost of memory fences on today's hardware platforms. The core contribution of this paper is to demonstrate, through comprehensive empirical evaluation, that the volatile-by-default semantics is arguably acceptable for a predominant use case for Java today – server-side applications running on Intel x86 architectures. We present VBD-HotSpot, a modification to Oracle's widely used HotSpot JVM that implements the volatile-by-default semantics for x86. To our knowledge VBD-HotSpot is the first implementation of SC for Java in the context of a modern JVM. VBD-HotSpot incurs an average overhead versus the baseline HotSpot JVM of 28% for the Da Capo benchmarks, which is significant though perhaps less than commonly assumed. Further, VBD-HotSpot incurs average overheads of 12% and 19% respectively on standard benchmark suites for big-data analytics and machine learning in the widely used Spark framework.

Wed 25 Oct

Displayed time zone: Tijuana, Baja California change

10:30 - 12:00
PerformanceOOPSLA at Regency C
Chair(s): Kathryn S McKinley Google
10:30
22m
Talk
A Volatile-by-Default JVM for Server Applications
OOPSLA
Lun Liu University of California at Los Angeles, USA, Todd Millstein University of California, Los Angeles, Madan Musuvathi Microsoft Research
DOI
10:52
22m
Talk
Static Placement of Computation on Heterogeneous Devices
OOPSLA
Gabriel Poesia Federal University of Minas Gerais, Brazil, Breno Campos Ferreira Guimarães Federal University of Minas Gerais, Brazil, Fabrício Ferracioli LG Electronics, Brazil, Fernando Magno Quintão Pereira UFMG
DOI
11:15
22m
Talk
Skip Blocks: Reusing Execution History to Accelerate Web Scripts
OOPSLA
Sarah E. Chasins University of California, Berkeley, Rastislav Bodík University of Washington
DOI
11:37
22m
Talk
Virtual Machine Warmup Blows Hot and Cold
OOPSLA
Edd Barrett King's College London, CF Bolz-Tereick , Rebecca Killick Department of Mathematics and Statistics, University of Lancaster, Sarah Mount King's College London, Laurence Tratt King's College London
DOI