The scope of OOPSLA includes all aspects of programming languages and software engineering, broadly construed.

Papers that address any aspect of software development are welcome, including requirements, modeling, prototyping, design, implementation, generation, analysis, verification, testing, evaluation, maintenance, reuse, replacement, and retirement of software systems. Papers may address these topics in a variety of ways, including new tools (such as languages, program analyses, and runtime systems), new techniques (such as methodologies, design processes, code organization approaches, and management techniques), and new evaluations (such as formalisms and proofs, corpora analyses, user studies, and surveys).

Distinguished Paper Awards

Dates
You're viewing the program in a time zone which is different from your device's time zone change time zone

Wed 28 Oct

Displayed time zone: Eastern Time (US & Canada) change

10:30 - 12:00
1. Model CheckingOOPSLA at Grand Station 1
Chair(s): Julian Dolby IBM Research
10:30
22m
Talk
Detecting Redundant CSS Rules in HTML5 Applications: A Tree Rewriting ApproachOOPSLA Artifact
OOPSLA
Anthony Widjaja Lin Yale-NUS College, Singapore, Matthew Hague Royal Holloway University of London, UK, C.-H. Luke Ong University of Oxford, UK
Link to publication
10:52
22m
Talk
SATCheck: SAT-Directed Stateless Model Checking for SC and TSOOOPSLA Artifact
OOPSLA
Brian Demsky University of California at Irvine, USA, Patrick Lam University of Waterloo, Canada
Link to publication
11:15
22m
Talk
Programming with Enumerable Sets of Structures
OOPSLA
Ivan Kuraj Massachusetts Institute of Technology, USA, Viktor Kunčak EPFL, Switzerland, Daniel Jackson Massachusetts Institute of Technology, USA
DOI
11:37
22m
Talk
Stateless Model Checking of Event-Driven Applications
OOPSLA
Casper Svenning Jensen Aarhus University, Denmark, Anders Møller Aarhus University, Veselin Raychev ETH Zurich, Switzerland, Dimitar Dimitrov ETH Zurich, Switzerland, Martin Vechev ETH Zurich, Switzerland
DOI
10:30 - 12:00
2. Domain Specific LanguagesOOPSLA at Grand Station 2
Chair(s): Eelco Visser Delft University of Technology
10:30
22m
Talk
Synthesis of Layout Engines from Relational Constraints
OOPSLA
Thibaud Hottelier Graphistry, Inc, Rastislav Bodík University of Washington, USA
Link to publication Media Attached
10:52
22m
Talk
A Sound and Optimal Incremental Build System with Dynamic DependenciesOOPSLA Artifact
OOPSLA
Sebastian Erdweg TU Darmstadt, Germany, Moritz Lichter TU Darmstadt, Germany, Manuel Weiel TU Darmstadt, Germany
Link to publication Media Attached
11:15
22m
Talk
FlashMeta: A Framework for Inductive Program Synthesis
OOPSLA
Alex Polozov University of Washington, USA, Sumit Gulwani Microsoft Research, USA
Link to publication DOI Media Attached
11:37
22m
Talk
Scrap your Boilerplate with Object AlgebrasOOPSLA Artifact
OOPSLA
Haoyuan Zhang University of Hong Kong, China, Zewei Chu University of Hong Kong, China, Bruno C. d. S. Oliveira University of Hong Kong, China, Tijs van der Storm CWI
Link to publication Media Attached
13:30 - 15:00
3. VerificationOOPSLA at Grand Station 1
Chair(s): Guangtai Liang IBM Research - China
13:30
22m
Talk
Conditionally Correct Superoptimization
OOPSLA
Rahul Sharma Stanford University, Eric Schkufza Stanford University, Berkeley Churchill Stanford University, Alex Aiken Stanford University
DOI
13:52
22m
Talk
Selective Control-Flow Abstraction via JumpingOOPSLA Artifact
OOPSLA
Sam Blackshear University of Colorado at Boulder, USA, Bor-Yuh Evan Chang University of Colorado at Boulder, USA, Manu Sridharan Samsung Research America
Link to publication
14:15
22m
Talk
Automating Grammar ComparisonOOPSLA Artifact
OOPSLA
Ravichandhran Madhavan EPFL, Switzerland, Mikaël Mayer EPFL, Switzerland, Sumit Gulwani Microsoft Research, USA, Viktor Kunčak EPFL, Switzerland
Link to publication
14:37
22m
Talk
Reasoning about the POSIX File System: Local Update and Global Pathnames
OOPSLA
Gian Ntzik Imperial College London, UK, Philippa Gardner Imperial College London, UK
DOI
15:30 - 17:00
4. ConcurrencyOOPSLA at Grand Station 1
Chair(s): Wolfgang De Meuter Vrije Universiteit Brussel
15:30
22m
Talk
AutoMO: Automatic Inference of Memory Order Parameters for C/C++11OOPSLA Artifact
OOPSLA
Peizhao Ou University of California at Irvine, USA, Brian Demsky University of California at Irvine, USA
DOI
15:52
22m
Talk
Valor: Efficient, Software-Only Region Conflict ExceptionsOOPSLA Artifact
OOPSLA
Swarnendu Biswas Ohio State University, USA, Minjia Zhang Ohio State University, USA, Michael D. Bond Ohio State University, USA, Brandon Lucia Carnegie Mellon University, USA
DOI Pre-print
16:15
22m
Talk
Automatic Memory Reclamation for Lock-Free Data Structures
OOPSLA
Nachshon Cohen Technion, Israel, Erez Petrank Technion, Israel
DOI
16:37
22m
Talk
Protocol-Based Verification of Message-Passing Parallel ProgramsOOPSLA Artifact
OOPSLA
Hugo A. López Technical University of Denmark, Eduardo Marques University of Lisbon, Portugal, Francisco Martins University of Lisbon, Portugal, Nicholas Ng Imperial College London, UK, César Santos University of Lisbon, Portugal, Vasco T. Vasconcelos University of Lisbon, Portugal, Nobuko Yoshida Imperial College London, UK
Link to publication

Thu 29 Oct

Displayed time zone: Eastern Time (US & Canada) change

10:30 - 12:00
5. MobilityOOPSLA at Grand Station 1
Chair(s): Lukasz Ziarek State University of New York (SUNY) Buffalo
10:30
22m
Talk
Interactively Verifying Absence of Explicit Information Flows in Android Apps
OOPSLA
Osbert Bastani Stanford University, Saswat Anand Stanford University, Alex Aiken Stanford University
DOI Media Attached
10:52
22m
Talk
ShamDroid: Gracefully Degrading Functionality in the Presence of Limited Resource Access
OOPSLA
Lucas Brutschy ETH Zurich, Switzerland, Pietro Ferrara IBM Research, USA, Omer Tripp IBM Research, USA, Marco Pistoia IBM Research, USA
Pre-print Media Attached
11:15
22m
Talk
Scalable Race Detection for Android ApplicationsOOPSLA Artifact
OOPSLA
Pavol Bielik ETH Zurich, Switzerland, Veselin Raychev ETH Zurich, Switzerland, Martin Vechev ETH Zurich, Switzerland
DOI Media Attached
11:37
22m
Talk
Versatile yet Lightweight Record-and-Replay for Android
OOPSLA
Yongjian Hu University of California at Riverside, USA, Tanzirul Azim University of California at Riverside, USA, Iulian Neamtiu University of California at Riverside, USA
DOI Media Attached
10:30 - 12:00
6. Compilation and ToolsOOPSLA at Grand Station 2
Chair(s): Gorel Hedin Lund University
10:30
22m
Talk
Declarative Fence InsertionOOPSLA Artifact
OOPSLA
John Bender University of California at Los Angeles, USA, Mohsen Lesani MIT, Jens Palsberg University of California at Los Angeles, USA
Link to publication
10:52
22m
Talk
Finding Deep Compiler Bugs via Guided Stochastic Program Mutation
OOPSLA
Vu Le University of California at Davis, USA, Chengnian Sun University of California at Davis, USA, Zhendong Su University of California at Davis, USA
DOI
11:15
22m
Talk
Vectorization of Apply to Reduce Interpretation Overhead of ROOPSLA Artifact
OOPSLA
Haichuan Wang University of Illinois at Urbana-Champaign, David Padua University of Illinois at Urbana-Champaign, Peng Wu Huawei America Lab
DOI
11:37
22m
Talk
Synthesizing Java Expressions from Free-Form Queries
OOPSLA
Tihomir Gvero EPFL, Switzerland, Viktor Kunčak EPFL, Switzerland
Link to publication
13:30 - 15:00
7. RuntimeOOPSLA at Grand Station 1
Chair(s): Michael Pradel TU Darmstadt, Germany
13:30
22m
Talk
Accurate Profiling in the Presence of Dynamic CompilationOOPSLA Artifact
OOPSLA
Yudi Zheng University of Lugano, Lubomír Bulej Università della Svizzera italiana, Walter Binder University of Lugano
DOI
13:52
22m
Talk
Fast, Multicore-Scalable, Low-Fragmentation Memory Allocation through Large Virtual Memory and Global Data StructuresOOPSLA Artifact
OOPSLA
Martin Aigner University of Salzburg, Austria, Christoph Kirsch University of Salzburg, Austria, Michael Lippautz University of Salzburg, Austria, Ana Sokolova University of Salzburg, Austria
DOI Pre-print Media Attached
14:15
22m
Talk
Probability Type Inference for Flexible Approximate Programming
OOPSLA
Brett Boston Massachusetts Institute of Technology, USA, Adrian Sampson Cornell University & Microsoft Research, Dan Grossman University of Washington, USA, Luis Ceze University of Washington, USA
Pre-print Media Attached
14:37
22m
Talk
Cross-Layer Memory Management for Managed Language Applications
OOPSLA
Michael Jantz University of Tennessee, USA, Forrest Robinson University of Kansas, USA, Prasad Kulkarni University of Kansas, Kshitij Doshi Intel, USA
DOI Media Attached
15:30 - 17:30
8. Static AnalysisOOPSLA at Grand Station 1
Chair(s): Werner Dietl University of Waterloo
15:30
24m
Talk
Static Analysis of Event-Driven Node.js JavaScript Applications
OOPSLA
Magnus Madsen University of Waterloo, Frank Tip Samsung Research America, Ondřej Lhoták University of Waterloo
DOI Media Attached
15:54
24m
Talk
EXPLORER : Query- and Demand-Driven Exploration of Interprocedural Control Flow Properties
OOPSLA
Yu Feng University of Texas at Austin, USA, Xinyu Wang UT Austin, Işıl Dillig University of Texas at Austin, USA, Calvin Lin University of Texas at Austin, USA
Pre-print Media Attached
16:18
24m
Talk
Giga-Scale Exhaustive Points-To Analysis for Java in Under a MinuteOOPSLA Artifact
OOPSLA
Jens Dietrich Massey University, New Zealand, Nicholas Hollingum University of Sydney, Australia, Bernhard Scholz Oracle Labs, Australia
DOI Media Attached
16:42
24m
Talk
Galois Transformers and Modular Abstract Interpreters: Reusable Metatheory for Program Analysis
OOPSLA
David Darais University of Maryland, College Park, Matthew Might University of Utah, USA, David Van Horn University of Maryland at College Park, USA
DOI Media Attached
17:06
24m
Talk
Learning a Strategy for Adapting a Program Analysis via Bayesian Optimisation
OOPSLA
Hakjoo Oh Korea University, South Korea, Hongseok Yang University of Oxford, UK, Kwangkeun Yi Seoul National University, South Korea
DOI Media Attached

Fri 30 Oct

Displayed time zone: Eastern Time (US & Canada) change

10:30 - 12:00
9. Compilation & Dynamic AnalysisOOPSLA at Grand Station 1
Chair(s): Frank Tip Samsung Research America
10:30
22m
Talk
Runtime Pointer DisambiguationOOPSLA Artifact
OOPSLA
Pericles Rafael Alves Federal University of Minas Gerais, Brazil, Fabian Gruber INRIA, France, Johannes Doerfert Saarland University, Alexandros Labrineas INRIA, France, Tobias Grosser ETH Zurich, Switzerland, Fabrice Rastello INRIA, France, Fernando Magno Quintão Pereira Federal University of Minas Gerais, Brazil
Link to publication
10:52
22m
Talk
Performance Problems You Can Fix: A Dynamic Analysis of Memoization OpportunitiesOOPSLA Artifact
OOPSLA
Luca Della Toffola ETH Zurich, Switzerland, Michael Pradel TU Darmstadt, Germany, Thomas Gross ETH Zurich, Switzerland
DOI
11:15
22m
Talk
RAIVE: Runtime Assessment of Floating-Point Instability by Vectorization
OOPSLA
Wen-Chuan Lee Purdue University, USA, Tao Bao Purdue University, USA, Yunhui Zheng IBM Research, Xiangyu Zhang Purdue University, USA, Keval Vora University of California at Riverside, USA, Rajiv Gupta University of California at Riverside, USA
DOI
11:37
22m
Talk
Automated Backward Error Analysis for Numerical Code
OOPSLA
Zhoulai Fu University of California at Davis, USA, Zhaojun Bai University of California at Davis, USA, Zhendong Su University of California at Davis, USA
DOI
10:30 - 12:00
10. Empirical Studies & ApproximationOOPSLA at Grand Station 2
Chair(s): John Field Google
10:30
22m
Talk
Using C Language Extensions for Developing Embedded Software: A Case Study
OOPSLA
Markus Völter itemis, Germany, Arie van Deursen Delft University of Technology, Netherlands, Bernd Kolb itemis AG, Stephan Eberle itemis AG
DOI Pre-print Media Attached
10:52
22m
Talk
How Scale Affects Structure in Java ProgramsOOPSLA Artifact
OOPSLA
Crista Lopes University of California, Irvine, Joel Ossher University of California, Irvine
DOI Pre-print Media Attached File Attached
11:15
22m
Talk
Use at Your Own Risk: The Java Unsafe API in the WildOOPSLA Artifact
OOPSLA
Luis Mastrangelo University of Lugano, Switzerland, Luca Ponzanelli University of Lugano, Switzerland, Andrea Mocci University of Lugano, Switzerland, Michele Lanza University of Lugano, Switzerland, Matthias Hauswirth University of Lugano, Switzerland, Nate Nystrom University of Lugano, Switzerland
DOI Media Attached
11:37
22m
Talk
Approximate Computation with Outlier Detection in TopazOOPSLA Artifact
OOPSLA
Sara Achour Massachusetts Institute of Technology, USA, Martin C. Rinard Massachusetts Institute of Technology, USA
DOI Media Attached
13:30 - 15:00
11. Programming Language DesignOOPSLA at Grand Station 1
Chair(s): Gary T. Leavens University of Central Florida
13:30
22m
Talk
Remote-Scope Promotion: Clarified, Rectified, and VerifiedOOPSLA Artifact
OOPSLA
John Wickerson Imperial College London, Mark Batty University of Cambridge, Bradford M. Beckmann Advanced Micro Devices, Inc, Alastair F. Donaldson Imperial College London
DOI Media Attached
13:52
22m
Talk
Incremental Computation with NamesOOPSLA Artifact
OOPSLA
Matthew Hammer University of Maryland, College Park, Jana Dunfield University of British Columbia, Canada, Kyle Headley University of Maryland, College Park, Nicholas Labich University of Maryland at College Park, USA, Jeffrey S. Foster University of Maryland at College Park, USA, Michael Hicks University of Maryland at College Park, USA, David Van Horn University of Maryland at College Park, USA
DOI
14:15
22m
Talk
Checks and Balances: Constraint Solving without Surprises in Object-Constraint Programming LanguagesOOPSLA Artifact
OOPSLA
Tim Felgentreff HPI, Germany, Todd Millstein University of California at Los Angeles, USA, Alan Borning University of Washington, USA, Robert Hirschfeld HPI
DOI
14:37
22m
Talk
Optimizing Hash-Array Mapped Tries for Fast and Lean Immutable JVM CollectionsOOPSLA Artifact
OOPSLA
Michael Steindorfer CWI, Netherlands, Jurgen Vinju CWI, Netherlands
Link to publication
13:30 - 15:00
12. PerformanceOOPSLA at Grand Station 2
Chair(s): Tiark Rompf Purdue & Oracle Labs
13:30
22m
Talk
Automating Ad-hoc Data Representation TransformationsOOPSLA Artifact
OOPSLA
Vlad Ureche EPFL, Switzerland, Aggelos Biboudis University of Athens, Yannis Smaragdakis University of Athens, Martin Odersky EPFL, Switzerland
Pre-print Media Attached
13:52
22m
Talk
Tracing vs. Partial Evaluation: Comparing Meta-compilation Approaches for Self-Optimizing InterpretersOOPSLA Artifact
OOPSLA
Stefan Marr INRIA, France, Stéphane Ducasse INRIA, France
Link to publication Media Attached
14:15
22m
Talk
Effectively Mapping Linguistic Abstractions for Message-Passing Concurrency to Threads on the Java Virtual Machine
OOPSLA
Ganesha Upadhyaya Iowa State University, USA, Hridesh Rajan Iowa State University, USA
DOI Pre-print Media Attached
14:37
22m
Talk
Partial Evaluation of Machine Code
OOPSLA
Venkatesh Srinivasan University of Wisconsin-Madison, USA, Thomas Reps University of Wisconsin - Madison and Grammatech Inc.
DOI Media Attached
15:30 - 17:00
13. Type SystemsOOPSLA at Grand Station 1
Chair(s): Nobuko Yoshida Imperial College London, UK
15:30
22m
Talk
A Co-Contextual Formulation of Type Rules and its Application to Incremental Type Checking
OOPSLA
Sebastian Erdweg TU Darmstadt, Germany, Oliver Bračevac TU Darmstadt, Edlira Kuci TU Darmstadt, Germany, Matthias Krebs TU Darmstadt, Germany, Mira Mezini TU Darmstadt
Link to publication Pre-print
15:52
22m
Talk
Disjointness Domains for Fine-Grained Aliasing
OOPSLA
Stephan Brandauer Uppsala University, Dave Clarke Uppsala University, Sweden and KU Leuven, Belgium, Tobias Wrigstad Uppsala University
Link to publication File Attached
16:15
22m
Talk
The Chemical Approach to Typestate-Oriented Programming
OOPSLA
Silvia Crafa Università di Padova, Italy, Luca Padovani
DOI
16:37
22m
Talk
Customizable Gradual Polymorphic Effects for ScalaOOPSLA Artifact
OOPSLA
Matías Toro University of Chile, Chile, Éric Tanter University of Chile, Chile
DOI

Accepted Papers

Title
Accurate Profiling in the Presence of Dynamic CompilationOOPSLA Artifact
OOPSLA
DOI
A Co-Contextual Formulation of Type Rules and its Application to Incremental Type Checking
OOPSLA
Link to publication Pre-print
Approximate Computation with Outlier Detection in TopazOOPSLA Artifact
OOPSLA
DOI Media Attached
A Sound and Optimal Incremental Build System with Dynamic DependenciesOOPSLA Artifact
OOPSLA
Link to publication Media Attached
Automated Backward Error Analysis for Numerical Code
OOPSLA
DOI
Automatic Memory Reclamation for Lock-Free Data Structures
OOPSLA
DOI
Automating Ad-hoc Data Representation TransformationsOOPSLA Artifact
OOPSLA
Pre-print Media Attached
Automating Grammar ComparisonOOPSLA Artifact
OOPSLA
Link to publication
AutoMO: Automatic Inference of Memory Order Parameters for C/C++11OOPSLA Artifact
OOPSLA
DOI
Checks and Balances: Constraint Solving without Surprises in Object-Constraint Programming LanguagesOOPSLA Artifact
OOPSLA
DOI
Conditionally Correct Superoptimization
OOPSLA
DOI
Cross-Layer Memory Management for Managed Language Applications
OOPSLA
DOI Media Attached
Customizable Gradual Polymorphic Effects for ScalaOOPSLA Artifact
OOPSLA
DOI
Declarative Fence InsertionOOPSLA Artifact
OOPSLA
Link to publication
Detecting Redundant CSS Rules in HTML5 Applications: A Tree Rewriting ApproachOOPSLA Artifact
OOPSLA
Link to publication
Disjointness Domains for Fine-Grained Aliasing
OOPSLA
Link to publication File Attached
Effectively Mapping Linguistic Abstractions for Message-Passing Concurrency to Threads on the Java Virtual Machine
OOPSLA
DOI Pre-print Media Attached
EXPLORER : Query- and Demand-Driven Exploration of Interprocedural Control Flow Properties
OOPSLA
Pre-print Media Attached
Fast, Multicore-Scalable, Low-Fragmentation Memory Allocation through Large Virtual Memory and Global Data StructuresOOPSLA Artifact
OOPSLA
DOI Pre-print Media Attached
Finding Deep Compiler Bugs via Guided Stochastic Program Mutation
OOPSLA
DOI
FlashMeta: A Framework for Inductive Program Synthesis
OOPSLA
Link to publication DOI Media Attached
Galois Transformers and Modular Abstract Interpreters: Reusable Metatheory for Program Analysis
OOPSLA
DOI Media Attached
Giga-Scale Exhaustive Points-To Analysis for Java in Under a MinuteOOPSLA Artifact
OOPSLA
DOI Media Attached
How Scale Affects Structure in Java ProgramsOOPSLA Artifact
OOPSLA
DOI Pre-print Media Attached File Attached
Incremental Computation with NamesOOPSLA Artifact
OOPSLA
DOI
Interactively Verifying Absence of Explicit Information Flows in Android Apps
OOPSLA
DOI Media Attached
Learning a Strategy for Adapting a Program Analysis via Bayesian Optimisation
OOPSLA
DOI Media Attached
Optimizing Hash-Array Mapped Tries for Fast and Lean Immutable JVM CollectionsOOPSLA Artifact
OOPSLA
Link to publication
Partial Evaluation of Machine Code
OOPSLA
DOI Media Attached
Performance Problems You Can Fix: A Dynamic Analysis of Memoization OpportunitiesOOPSLA Artifact
OOPSLA
DOI
Probability Type Inference for Flexible Approximate Programming
OOPSLA
Pre-print Media Attached
Programming with Enumerable Sets of Structures
OOPSLA
DOI
Protocol-Based Verification of Message-Passing Parallel ProgramsOOPSLA Artifact
OOPSLA
Link to publication
RAIVE: Runtime Assessment of Floating-Point Instability by Vectorization
OOPSLA
DOI
Reasoning about the POSIX File System: Local Update and Global Pathnames
OOPSLA
DOI
Remote-Scope Promotion: Clarified, Rectified, and VerifiedOOPSLA Artifact
OOPSLA
DOI Media Attached
Runtime Pointer DisambiguationOOPSLA Artifact
OOPSLA
Link to publication
SATCheck: SAT-Directed Stateless Model Checking for SC and TSOOOPSLA Artifact
OOPSLA
Link to publication
Scalable Race Detection for Android ApplicationsOOPSLA Artifact
OOPSLA
DOI Media Attached
Scrap your Boilerplate with Object AlgebrasOOPSLA Artifact
OOPSLA
Link to publication Media Attached
Selective Control-Flow Abstraction via JumpingOOPSLA Artifact
OOPSLA
Link to publication
ShamDroid: Gracefully Degrading Functionality in the Presence of Limited Resource Access
OOPSLA
Pre-print Media Attached
Stateless Model Checking of Event-Driven Applications
OOPSLA
DOI
Static Analysis of Event-Driven Node.js JavaScript Applications
OOPSLA
DOI Media Attached
Synthesis of Layout Engines from Relational Constraints
OOPSLA
Link to publication Media Attached
Synthesizing Java Expressions from Free-Form Queries
OOPSLA
Link to publication
The Chemical Approach to Typestate-Oriented Programming
OOPSLA
DOI
Tracing vs. Partial Evaluation: Comparing Meta-compilation Approaches for Self-Optimizing InterpretersOOPSLA Artifact
OOPSLA
Link to publication Media Attached
Use at Your Own Risk: The Java Unsafe API in the WildOOPSLA Artifact
OOPSLA
DOI Media Attached
Using C Language Extensions for Developing Embedded Software: A Case Study
OOPSLA
DOI Pre-print Media Attached
Valor: Efficient, Software-Only Region Conflict ExceptionsOOPSLA Artifact
OOPSLA
DOI Pre-print
Vectorization of Apply to Reduce Interpretation Overhead of ROOPSLA Artifact
OOPSLA
DOI
Versatile yet Lightweight Record-and-Replay for Android
OOPSLA
DOI Media Attached

Call for Papers

PAPER SELECTION

Selection Criteria

The program committee will consider the following criteria when evaluating submitted papers:

Novelty: The paper presents new ideas and/or results and places these ideas and results appropriately within the context established by previous research in the field.

Importance: The paper contributes significantly to the advancement of knowledge in the field. In addition to more traditional contributions, OOPSLA welcomes papers that diverge from the dominant trajectory of the field or challenge the existing value system.

Evidence: The paper presents sufficient evidence supporting its claims. Examples of evidence include proofs, implemented systems, experimental results, statistical analyses, case studies, and anecdotes.

Clarity: The paper presents its contributions, methodology and results clearly.

Selection Process

OOPSLA 2015 will follow a two-phase review process that was initiated in OOPSLA 2013, with the goal of improving the quality of accepted papers. The first reviewing phase assesses the papers using the criteria stated above. At the PC meeting a set of papers will be conditionally accepted and all other papers will be rejected.

Authors of conditionally accepted papers will be provided with the usual committee reviews along with a set of mandatory revisions. After two months, the authors will provide a second submission. The second and final reviewing phase assesses how well the mandatory revisions have been performed by the authors and thereby determines the final accept/reject status of the paper. The intent and expectation is that the mandatory revisions can be adequately addressed within two months and hence that conditionally accepted papers will be accepted in the second phase.

The second submission should clearly identify how the mandatory revisions were addressed. To that end, the second submission must be accompanied by a cover letter mapping each mandatory revision request to specific parts of the paper. The absence of this cover letter is grounds for the paper’s rejection.

SUBMISSION

OOPSLA 2015 submissions must conform to both the ACM Policy on Prior Publication and Simultaneous Submissions and the SIGPLAN Re-publication Policy. In addition, this year, OOPSLA is implementing double-blind submissions (i.e., authors are anonymous).

Submission Site

http://oopsla15.hotcrp.com

Format

Submissions should use the ACM SIGPLAN Conference Format, 10 point font. Note that by default the SIGPLAN Conference Format produces papers in 9 point font. If you are formatting your paper using LaTeX, you will need to set the 10pt option in the \documentclass command. If you are formatting your paper using Word, you may wish to use the provided Word template that supports this font size. Please include page numbers in your submission. Setting the preprint option in the LaTeX \documentclass command generates page numbers. Please also ensure that your submission is legible when printed on a black and white printer. In particular, please check that colors remain distinct and font sizes are legible.

Page Limit

To ensure that papers stay focused on their core contributions, the main part of the paper (including bibliographic references) should be no longer than 14 pages. There is no page limit for appendices, and, therefore, for the overall submission. However, reviewers are not obligated to read the appendices, so the main part of the paper should be self contained. If the paper is accepted, the final submission will be limited to 20 pages, including appendices.

Artifact Evaluation

Authors of papers that are conditionally accepted in the first phase will be invited to formally submit supporting materials to the Artifact Evaluation process. This submission is voluntary and will not influence the final decision regarding the papers. Papers that go through the Artifact Evaluation process successfully will receive a seal of approval printed on the papers themselves.

Authors of accepted papers are encouraged to make these materials publicly available upon publication of the proceedings, by including them as “source materials” in the ACM Digital Library.

Publication

AUTHORS TAKE NOTE: All accepted papers will be available in the ACM Digital Library as early as 21 October, 2015. The official publication date is the date the proceedings are made available in the ACM Digital Library. The official publication date affects the deadline for any patent filings related to published work.

More Information

For additional information, clarification, or answers to questions please contact the OOPSLA Chair (Patrick Eugster) at oopsla@splashcon.org.

The following content is strongly based on Mike Hick’s guidelines for POPL 2012, and has been honed by a number of authors including Frank Tip, Keshav Pingali, Richard Jones, and John Boyland.

General

Q: Why are you using double-blind reviewing?

A: Our goal is to give each a reviewer an unbiased “first look” at each paper. Studies have shown that a reviewer’s attitude toward a submission may be affected, even unconsciously, by the identity of the author (see link below to more details). We want reviewers to be able to approach each submission without such involuntary reactions as “Barnaby; he writes a good paper” or “Who are these people? I have never heard of them.” For this reason, we ask that authors to omit their names from their submissions, and that they avoid revealing their identity through citation. Note that many systems and security conferences use double-blind reviewing and have done so for years (e.g., PLDI, ASPLOS, SIGCOMM, OSDI, IEEE Security and Privacy, SIGMOD, ISMM).

A key principle to keep in mind is that we intend this process to be cooperative, not adversarial. If a reviewer does discover an author’s identity though a subtle clue or oversight the author will not be penalized.

For those wanting more information, see the list of studies about gender bias in other fields and links to CS-related articles that cover this and other forms of bias below.

Q: Do you really think blinding actually works? I suspect reviewers can often guess who the authors are anyway.

A: Studies of blinding with the flavor we are using show that author identities remain unknown 53% to 79% of the time (see Snodgrass, linked below, for details). Moreover, about 5-10% of the time (again, see Snodgrass), a reviewer is certain of the authors, but then turns out to be at least partially mistaken. Mike Hicks’s survey of POPL’12 PC and ERC members showed that they were often mistaken or surprised by the author’s identity. So, while sometimes authorship can be guessed correctly, the question is, is imperfect blinding better than no blinding at all? If author names are not explicitly in front of the reviewer on the front page, does that help at all even for the remaining submissions where it would be possible to guess? Our conjecture is that on balance the answer is “yes”.

Q: Couldn’t blind submission create an injustice where a paper is inappropriately rejected based upon supposedly-prior work which was actually by the same authors and not previously published?

A: In the approach we are taking for OOPSLA, author names are revealed to reviewers after they have submitted their review. Therefore, a reviewer can correct their review if they indeed have penalized the authors inappropriately. Unblinding prior to the PC meeting also avoids abuses in which committee members end up advancing the cause of a paper with which they have a conflict.

For Authors

Q: What exactly do I have to do to anonymize my paper?

A: Your job is not to make your identity undiscoverable but simply to make it possible for our reviewers to evaluate your submission without having to know who you are. The main guidelines are simple: omit authors’ names from your title page (or list them as “omitted for submission”), and when you cite your own work, refer to it in the third person. For example, if your name is Smith and you have worked on amphibious type systems, instead of saying “We extend our earlier work on statically typed toads (Smith 2004),” you might say “We extend Smith’s (2004) earlier work on statically typed toads.” Also, be sure not to include any acknowledgements that would give away your identity.

Q: I would like to provide supplementary material for consideration, e.g., the code of my implementation or proofs of theorems. How do I do this?

A: On the submission site there will be an option to submit supplementary material along with your main paper. This supplementary material need not be anonymized; it will only be revealed to reviewers after they have submitted their review of your paper and learned your identity. Reviewers are under no obligation to look at this material. The submission itself is the object of review and so it should strive to convince the reader of at least the plausibility of reported results; supplemental material only serves to confirm, in more detail, the idea argued in the paper. Of course, reviewers are free to change their review upon viewing supplemental material (or for any other reason). For those authors who wish to supplement, we encourage them to mention the supplement in the body of the paper. E.g., “The proof of Lemma 1 is included in the non-anonymous supplemental material submitted with this paper.”

Q: Is there a way for me to submit anonymous supplemental material which could be considered by a reviewer before she submits her review (rather than potentially non-anonymous material that can only be viewed afterward)?

A: You may include additional material as an anonymized appendix to your paper. Reviewers are under no obligation to look at this material. That said, there is nothing stopping an author from releasing a TR, code, etc. via an anonymous hosting service, and including a URL to that material in the paper. We point out this option not to encourage authors to exercise it, but to make them aware it exists, since we know of others who have used it. We emphasize that authors should strive to make their paper as convincing as possible on its own, in case reviewers choose not to access supplemental material.

Q: I am building on my own past work on the WizWoz system. Do I need to rename this system in my paper for purposes of anonymity, so as to remove the implied connection between my authorship of past work on this system and my present submission?

A: No, you must not change the name. The relationship between systems and authors changes over time, so there will be at least some doubt about authorship. Increasing this doubt by changing the system name would help with anonymity, but it would compromise the research process. In particular, changing the name requires explaining a lot about the system again because you can’t just refer to the existing papers, which use the proper name. Not citing these papers runs the risk of the reviewers who know about the existing system thinking you are replicating earlier work. It is also confusing for the reviewers to read about the paper under Name X and then have the name be changed to Name Y. Will all the reviewers go and re-read the final version with the correct name? If not, they have the wrong name in their heads, which could be harmful in the long run.

Q: I am submitting a paper that extends my own work that previously appeared at a workshop. Should I anonymize any reference to that prior work?

A: No. But we recommend you do not use the same title for your OOPSLA submission, so that it is clearly distinguished from the prior paper. In general there is rarely a good reason to anonymize a citation. One possibility is for work that is tightly related to the present submission and is also under review. But such works may often be non-anonymous. When in doubt, contact the PC Chair.

Q: Am I allowed to post my (non-blinded) paper on my web page? Can I advertise the unblinded version of my paper on mailing lists or send it to colleagues? May I give a talk about my work while it is under review?

A: As far as the authors’ publicity actions are concerned, a paper under double-blind review is largely the same as a paper under regular (single-blind) review. Double-blind reviewing should not hinder the usual communication of results.

That said, we do ask that you not attempt to deliberately subvert the double-blind reviewing process by announcing the names of the authors of your paper to the potential reviewers of your paper. It is difficult to define exactly what counts as “subversion” here, but some blatant examples include: sending individual e-mail to members of the PC about your work (unless they are conflicted out anyway), or posting mail to a major mailing list (e.g. TYPES) announcing your paper. On the other hand, it is perfectly fine, for example, to visit other institutions and give talks about your work, to present your submitted work during job interviews, to present your work at professional meetings (e.g. Dagstuhl), or to post your work on your web page. PC members will not be asked to recuse themselves from reviewing your paper unless they feel you have gone out of your way to advertise your authorship information to them. If you’re not sure about what constitutes “going out of your way”, please consult directly with the Programme Chair.

Q: Will the fact that OOPSLA is double-blind have an impact on handling conflicts-of interest? When I am asked by the submission system to identify conflicts of interest, what criteria should I use?

A: Using DBR does not change the principle that reviewers should not review papers with which they have a conflict of interest, even if they do not immediately know who the authors are.

As an author, you should list PC members (and any others, since others may be asked for outside reviewers) who you believe have a conflict with you. While particular criteria for making this determination may vary, the AITO guidelines indicate a potential conflict with:

  1. Your graduate supervisors and students.
  2. Members of your current research team.
  3. A co-author of a paper in the last five years.
  4. A member of your family or a close personal friend.
  5. Someone with whom you have a significant financial relationship .
  6. An employee of the organization you work for (including an academic department).

There is (perhaps fortunately, perhaps not) room for interpretation in many of these. Example: If you work for a large company or a multi-campus university, do you have a conflict with all other employees? Well, even the U.S. National Science Foundation permits members of one campus to waive conflicts with members of the other campuses. There might be similar border line situations with large European projects. When you’re unsure, ask the programme chair for advice.

If a possible reviewer does not meet the above criteria, please do not identify him/her as conflicted. Doing so could be viewed as an attempt to prevent a qualified, but possibly skeptical reviewer from reviewing your paper. If you nevertheless believe that a reviewer who does not meet the above criteria is conflicted, you may identify the person and send a note to the PC Chair.

For Reviewers

Q: What should I do if I if I learn the authors’ identity? What should I do if a prospective OOPSLA author contacts me and asks to visit my institution?

A: If at any point you feel that the authors’ actions are largely aimed at ensuring that potential reviewers know their identity, you should contact the Programme Chair. Otherwise you should not treat double-blind reviewing differently from regular blind reviewing. In particular, you should refrain from seeking out information on the authors’ identity, but if you discover it accidentally this will not automatically disqualify you as a reviewer. Use your best judgment.

Q: The authors have provided a URL to supplemental material. I would like to see the material but I worry they will snoop my IP address and learn my identity. What should I do?

A: Contact the Programme Chair, who will download the material on your behalf and make it available to you.

Q: If I am assigned a paper for which I feel I am not an expert, how do I seek an outside review?

A: PC members should do their own reviews, not delegate them to someone else. If doing so is problematic for some papers, e.g., you don’t feel completely qualified, then consider the following options. First, submit a review for your paper that is as careful as possible, outlining areas where you think your knowledge is lacking. Assuming we have sufficient expert reviews, that could be the end of it: non-expert reviews are valuable too, since conference attendees are by-and-large not experts for any given paper. Second, the review form provides a mechanism for suggesting additional expert reviewers to the PC Chair, who may contact them if additional expertise is needed. Please do NOT contact outside reviewers yourself. As a last resort, if you feel like your review would be extremely uninformed and you’d rather not even submit a first cut, contact the PC Chair, and another reviewer will be assigned.

Q: How do we handle potential conflicts of interest since I cannot see the author names?

A: The conference review system will ask that you identify conflicts of interest when you get an account on the submission system. Please see the related question applied to authors to decide how to identify conflicts. Feel free to also identify additional authors whose papers you feel you could not review fairly for reasons other than those given (e.g., strong personal friendship).

More information about bias in merit reviewing

Kathryn McKinley’s editorial makes the case for double-blind reviewing from a computer science perspective. Her article cites Richard Snodgrass’s SIGMOD record editorial which collects many studies of the effects of potential bias in peer review. Mike Hicks’s Chair’s Report describes how POPL’12 used double-blind reviewing and analyzes its effectiveness.

Here are a few studies on the potential effects of bias manifesting in a merit review process, focusing on bias against women. (These were collected by David Wagner.)

  • There’s the famous story of gender bias in orchestra try-outs, where moving to blind auditions seems to have increased the hiring of female musicians by up to 33% or so. Today some orchestras even go so far as to ask musicians to remove their shoes (or roll out thick carpets) before auditioning, to try to prevent gender-revealing cues from the sound of the auditioner’s shoes.

  • One study found bias in assessment of identical CVs but with names and genders changed. In particular, the researchers mailed out c.v.’s for a faculty position, but randomly swapped the gender of the name on some of them. They found that both men and women reviewers ranked supposedly-male job applicants higher than supposedly-female applicants – even though the contents of the c.v. were identical. Presumably, none of the reviewers thought of themselves as biased, yet their evaluations in fact exhibited gender bias. (However: in contrast to the gender bias at hiring time, if the reviewers were instead asked to evaluate whether a candidate should be granted tenure, the big gender differences disappeared. For whatever that’s worth.)

  • The Implicit Association Test illustrates how factors can bias our decision-making, without us realising it. For instance, a large fraction of the population has a tendency to associate men with career (professional life) and women with family (home life), without realizing it. The claim is that we have certain gender stereotypes and schemas which unconsciously influence the way we think. The interesting thing about the IAT is that you can take it yourself. If you want to give it a try, select the Gender-Career IAT or the Gender-Science IAT from here. There’s evidence that these unconscious biases affect our behavior. For instance, one study of recommendation letters written for 300 applicants (looking only at the ones who were eventually hired) found that, when writing about men, letter-writers were more likely to highlight the applicant’s research and technical skills, while when writing about women, letter-writers were more likely to mention the applicant’s teaching and interpersonal skills.

  • This study reports experience from an ecology journal that switched from non-blind to blind reviewing. After the switch, they found a significant (~8%) increase in the acceptance rate for female-first-authored submissions. To put it another way, they saw a 33% increase in the fraction of published papers whose first author is female (28% -> 37%). Keep in mind that this is not a controlled experiment, so it proves correlation but not causation, and there appears to be controversy in the literature about the work. So it as at most a plausibility result that gender bias could be present in the sciences, but far from definitive.

Snodgrass’ studies includes some of these, and more.