PLDI is a premier forum for all areas of programming language research, including the design, implementation, theory, and efficient use of languages. PLDI seeks outstanding research that has broad appeal to the entire programming languages community.

A recently updated Practices of PLDI is now available for reference and comments.

PLDI will take place June 15-17 (workshops and tutorials will take place June 13-14).

The PLDI’16 technical papers are available (once the conference starts and for one month following) via 1-click download from the ACM Digital Library.

Wed 15 Jun

Thu 16 Jun

Fri 17 Jun

Call for Contributions

PLDI is a premier forum for all areas of programming language research, including the design, implementation, theory, and efficient use of languages. PLDI seeks outstanding research that has broad appeal and spans the breadth of programming languages.


Please note that formatting requirements for PLDI’16 may be different from previous years. Details can be found in the Instructions for Authors. The submission site is

To enable double-blind reviewing, author names and their affiliations must be omitted from submissions, and references to related work by the authors should be in the third person (e.g., not “We build on our previous work …” but rather “We build on the work of …”). However, nothing should be done in the name of anonymity that weakens the submission or makes the job of reviewing the paper more difficult (e.g., important background references should not be omitted or anonymized). If you have questions about the logistics for the double-blind reviewing process, please look at the double-blind reviewing FAQ (or click on tab above).

Papers must describe unpublished work that is not currently submitted for publication elsewhere as described by SIGPLAN’s Republication Policy. Submitters should also be aware of ACM’s Policy and Procedures on Plagiarism.

Evaluation Criteria

The program committee and the external review committee will evaluate the technical contribution of each submission as well as its general accessibility to the PLDI audience. Papers will be judged on significance, originality, and clarity. The paper must be organized so that it is easily understood by an audience with varied expertise. The paper should clearly identify what has been accomplished, why it is significant, and how it relates to previous work.

Artifact Evaluation Process

Authors of accepted papers will be invited to formally submit these supporting materials to the Artifact Evaluation process. The Artifact Evaluation process is run by a separate committee whose task is to assess how the artifacts support the work described in the papers. 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. Additional information will be available on the PLDI AEC web page closer to the submission deadline.


Authors of accepted papers will be required to sign an ACM copyright release.

AUTHORS TAKE NOTE: The official publication date is the date the proceedings are made available in the ACM Digital Library. This date may be up to two weeks prior to the first day of your conference. The official publication date affects the deadline for any patent filings related to published work. (For those rare conferences whose proceedings are published in the ACM Digital Library after the conference is over, the official publication date remains the first day of the conference.)

Accepted Papers

Media Attached
Media Attached
Link to publication DOI Media Attached
Media Attached
Media Attached
Media Attached
Media Attached
Media Attached
Media Attached
Media Attached
Media Attached
Media Attached
Pre-print Media Attached
Pre-print Media Attached
Pre-print Media Attached
Media Attached
Media Attached
DOI Media Attached
Link to publication Media Attached
Pre-print Media Attached
Media Attached
Media Attached
Link to publication Media Attached
Media Attached
Media Attached
Media Attached
Media Attached
Pre-print Media Attached
Media Attached
Pre-print Media Attached
Pre-print Media Attached
Media Attached
Pre-print Media Attached
Link to publication Media Attached
Media Attached
Pre-print Media Attached
Media Attached
Media Attached
Media Attached
Media Attached
Media Attached
DOI Pre-print Media Attached
Media Attached
Media Attached
Pre-print Media Attached
Media Attached
Pre-print Media Attached
Media Attached
Pre-print Media Attached
Media Attached

PLDI 2016- Proceedings of the 37th ACM SIGPLAN Conference on Programming Language Design and Implementation

Full Citation in the ACM Digital Library

PLDI Keynote Presentation: Dr. Ben Zorn, Microsoft Research: Programming Languages and Technical Disruption

Down to the Metal I (Grand Ballroom Santa Ynez - Wednesday 10:30-12:00, Session Chair: Stephen McCamant)

Into the depths of C: elaborating the de facto standards

  • Kayvan Memarian
  • Justus Matthiesen
  • James Lingard
  • Kyndylan Nienhuis
  • David Chisnall
  • Robert N. M. Watson
  • Peter Sewell

Living on the edge: rapid-toggling probes with cross-modification on x86

  • Buddhika Chamith
  • Bo Joel Svensson
  • Luke Dalessandro
  • Ryan R. Newton

Polymorphic type inference for machine code

  • Matt Noonan
  • Alexey Loginov
  • David Cok

Verification I (Grand Ballroom San Rafael - Wednesday 10:30-12:00, Session Chair: Isil Dillig)

Data-driven precondition inference with learned features

  • Saswat Padhi
  • Rahul Sharma
  • Todd Millstein

Cartesian hoare logic for verifying k-safety properties

  • Marcelo Sousa
  • Isil Dillig

Verifying bit-manipulations of floating-point

  • Wonyeol Lee
  • Rahul Sharma
  • Alex Aiken

Testing and Debugging (Grand Ballroom Santa Ynez - Wednesday 13:30-15:00, Session Chair: Ben Zorn)

Coverage-directed differential testing of JVM implementations

  • Yuting Chen
  • Ting Su
  • Chengnian Sun
  • Zhendong Su
  • Jianjun Zhao

Exposing errors related to weak memory in GPU applications

  • Tyler Sorensen
  • Alastair F. Donaldson

Lightweight computation tree tracing for lazy functional languages

  • Maarten Faddegon
  • Olaf Chitil

Energy and Performance (Grand Ballroom San Rafael - Wednesday 13:30-15:00, Session Chair: Manuel Hermenegildo)

Effective padding of multidimensional arrays to avoid cache conflict misses

  • Changwan Hong
  • Wenlei Bao
  • Albert Cohen
  • Sriram Krishnamoorthy
  • Louis-Noël Pouchet
  • Fabrice Rastello
  • J. Ramanujam
  • P. Sadayappan

GreenWeb: language extensions for energy-efficient mobile web computing

  • Yuhao Zhu
  • Vijay Janapa Reddi

Input responsiveness: using canary inputs to dynamically steer approximation

  • Michael A. Laurenzano
  • Parker Hill
  • Mehrzad Samadi
  • Scott Mahlke
  • Jason Mars
  • Lingjia Tang

New Languages (Grand Ballroom Santa Ynez - Wednesday 15:30-17:00, Session Chair: Michael Carbin)

Configuration synthesis for programmable analog devices with Arco

  • Sara Achour
  • Rahul Sarpeshkar
  • Martin C. Rinard

From Datalog to flix: a declarative language for fixed points on lattices

  • Magnus Madsen
  • Ming-Ho Yee
  • Ondřej Lhoták

Latte: a language, compiler, and runtime for elegant and efficient deep neural networks

  • Leonard Truong
  • Rajkishore Barik
  • Ehsan Totoni
  • Hai Liu
  • Chick Markley
  • Armando Fox
  • Tatiana Shpeisman

Parsing and Compilation (Grand Ballroom San Rafael - Wednesday 15:30-17:00, Session Chair: Michelle Mills Strout)

Automatic Storage Optimization for Arrays [TOPLAS]

  • Somashekaracharya G Bhaskaracharya
  • Uday Bondhugula
  • Albert Cohen

Polyhedral AST Generation is More Than Scanning Polyhedra [TOPLAS]

  • Tobias Grosser
  • Sven Verdoolaege
  • Albert Cohen

On the complexity and performance of parsing with derivatives

  • Michael D. Adams
  • Celeste Hollenbeck
  • Matthew Might

Down to the Metal II (Grand Ballroom Santa Ynez - Thursday 10:30-12:00, Session Chair: Hans-J. Boehm)

Stratified synthesis: automatically learning the x86-64 instruction set

  • Stefan Heule
  • Eric Schkufza
  • Rahul Sharma
  • Alex Aiken

Remix: online detection and repair of cache contention for the JVM

  • Ariel Eizenberg
  • Shiliang Hu
  • Gilles Pokam
  • Joseph Devietti

Statistical similarity of binaries

  • Yaniv David
  • Nimrod Partush
  • Eran Yahav

Types I (Grand Ballroom San Rafael - Thursday 10:30-12:00, Session Chair: David Walker)

Accepting blame for safe tunneled exceptions

  • Yizhou Zhang
  • Guido Salvaneschi
  • Quinn Beightol
  • Barbara Liskov
  • Andrew C. Myers

Occurrence typing modulo theories

  • Andrew M. Kent
  • David Kempe
  • Sam Tobin-Hochstadt

Refinement types for TypeScript

  • Panagiotis Vekris
  • Benjamin Cosman
  • Ranjit Jhala

Synthesis I (Grand Ballroom Santa Ynez - Thursday 13:30-15:00, Session Chair: Eran Yahav)

MapReduce program synthesis

  • Calvin Smith
  • Aws Albarghouthi

Programmatic and direct manipulation, together at last

  • Ravi Chugh
  • Brian Hempel
  • Mitchell Spradlin
  • Jacob Albers

Fast synthesis of fast collections

  • Calvin Loncaric
  • Emina Torlak
  • Michael D. Ernst

Software-Defined Networking (Grand Ballroom San Rafael - Thursday 13:30-15:00, Session Chair: Todd Millstein)

Event-driven network programming

  • Jedidiah McClurg
  • Hossein Hojjat
  • Nate Foster
  • Pavol Černý

Temporal NetKAT

  • Ryan Beckett
  • Michael Greenberg
  • David Walker

SDNRacer: concurrency analysis for software-defined networks

  • Ahmed El-Hassany
  • Jeremie Miserez
  • Pavol Bielik
  • Laurent Vanbever
  • Martin Vechev

Verifying Systems (Grand Ballroom Santa Ynez - Thursday 15:30-17:00, Session Chair: Santosh Nagarakatte)

Rehearsal: a configuration verification tool for puppet

  • Rian Shambaugh
  • Aaron Weiss
  • Arjun Guha

Toward compositional verification of interruptible OS kernels and device drivers

  • Hao Chen
  • Xiongnan (Newman) Wu
  • Zhong Shao
  • Joshua Lockerman
  • Ronghui Gu

Verified peephole optimizations for CompCert

  • Eric Mullen
  • Daryl Zuniga
  • Zachary Tatlock
  • Dan Grossman

Types II (Grand Ballroom San Rafael - Thursday 15:30-17:00, Session Chair: Jean Yang)

Just-in-time static type checking for dynamic languages

  • Brianna M. Ren
  • Jeffrey S. Foster

Types from data: making structured data first-class citizens in F#

  • Tomas Petricek
  • Gustavo Guerra
  • Don Syme

Automatically learning shape specifications

  • He Zhu
  • Gustavo Petri
  • Suresh Jagannathan

Synthesis II (Grand Ballroom Santa Ynez - Thursday 17:00-18:00, Session Chair: Martin Vechev)

Synthesizing transformations on hierarchically structured data

  • Navid Yaghmazadeh
  • Christian Klinger
  • Isil Dillig
  • Swarat Chaudhuri

Program synthesis from polymorphic refinement types

  • Nadia Polikarpova
  • Ivan Kuraj
  • Armando Solar-Lezama

Parallelism I (Grand Ballroom San Rafael - Friday 17:00-18:00, Session Chair: Tony Hosking)

Higher-order and tuple-based massively-parallel prefix sums

  • Sepideh Maleki
  • Annie Yang
  • Martin Burtscher

A distributed OpenCL framework using redundant computation and data replication

  • Junghyun Kim
  • Gangwon Jo
  • Jaehoon Jung
  • Jungwon Kim
  • Jaejin Lee

Memory Management (Grand Ballroom Santa Ynez - Friday 09:00-10:30, Session Chair: Sam Guyer)

Idle time garbage collection scheduling

  • Ulan Degenbaev
  • Jochen Eisinger
  • Manfred Ernst
  • Ross McIlroy
  • Hannes Payer

Assessing the limits of program-specific garbage collection performance

  • Nicholas Jacek
  • Meng-Chieh Chiu
  • Benjamin Marlin
  • Eliot Moss

Verification II (Grand Ballroom San Rafael - Friday 09:00-10:30, Armando Solar-Lezama)

Cardinalities and universal quantifiers for verifying parameterized systems

  • Klaus v. Gleissenthall
  • Nikolaj Bjørner
  • Andrey Rybalchenko

Ivy: safety verification by interactive generalization

  • Oded Padon
  • Kenneth L. McMillan
  • Aurojit Panda
  • Mooly Sagiv
  • Sharon Shoham

Security (Grand Ballroom Santa Ynez - Friday 10:30-12:00, Session Chair: Andrew Myers)

Precise, dynamic information flow for database-backed applications

  • Jean Yang
  • Travis Hance
  • Thomas H. Austin
  • Armando Solar-Lezama
  • Cormac Flanagan
  • Stephen Chong

End-to-end verification of information-flow security for C and assembly programs

  • David Costanzo
  • Zhong Shao
  • Ronghui Gu

A design and verification methodology for secure isolated regions

  • Rohit Sinha
  • Manuel Costa
  • Akash Lal
  • Nuno P. Lopes
  • Sriram Rajamani
  • Sanjit A. Seshia
  • Kapil Vaswani

Parallelism II (Grand Ballroom San Rafael - Friday 10:30-12:00, Session Chair: Albert Cohen)

Transactional data structure libraries

  • Alexander Spiegelman
  • Guy Golan-Gueta
  • Idit Keidar

FlexVec: auto-vectorization for irregular loops

  • Sara S. Baghsorkhi
  • Nalini Vasudevan
  • Youfeng Wu

Verified lifting of stencil computations

  • Shoaib Kamil
  • Alvin Cheung
  • Shachar Itzhaky
  • Armando Solar-Lezama

Authors of accepted papers will have received an author kit from the publisher. Here are the key highlights:

  • Paper must be submitted in printable PDF format.
  • Please use this style to format your paper, with the pldi-cameraready option: PLDI 2016 style file
  • Text must be in a minimum 10pt font (not 9pt).
  • Papers can be 15 pages long in US letter format, all inclusive. Authors may purchase two additional pages @ $100/page.
  • Each reference must specify all authors (no et al.).
  • Authors of all accepted papers will be required to give a lightning presentation (about 90 s) and a poster in addition to the regular conference talk.
  • Proceedings may appear in the ACM digital library as early as May 30, 2016.


Q: Why are you using double-blind reviewing?
A: Studies have shown that a reviewer's attitude toward a submission may be affected, even unconsciously, by the identity of the author. 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., SIGCOMM, OSDI, IEEE Security and Privacy, SIGMOD). PLDI has done it for several years now. 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.

Q: Do you really think blinding actually works? I suspect reviewers can often guess who the authors are anyway.
A: Authorship can be guessed correctly sometimes, but imperfect blinding is better than no blinding at all, we believe.

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: Reviewers are held accountable for their positions and are required to identify any supposed prior work that they believe undermines the novelty of the paper. Any assertion that 'this has been done before' must be supported with concrete information which can be checked by the PC Chair and by authors vial the author response mechanism. The author response mechanism exists in part to hold reviewers accountable for their positions; authors can and should correct any such misapprehension.

For authors

Q: What exactly do I have to do to anonymize my paper?
A: Use common sense. 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 specific guidelines stated in the call for papers are simple: omit authors' names from your title page, 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. In general, you should aim to reduce the risk of accidental unblinding. For example, if your paper is the first to describe a system with a well-known name or codename, or you use a personally-identifiable naming convention for your work, you must use a different name for your submission (which you may indicate has been changed for the purposes of double-blind reviewing). You should also avoid revealing the institution affiliation of authors or at which the work was performed.

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: (see the next question also) On the submission site there will be an option to submit supplementary material along with your main paper. This supplementary material should also be anonymized. 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 supplemental material submitted with this paper."

Q: My submission is based on code available in a public repository. How do I deal with this?
A: Making your code publicly available is not incompatible with the double blind process. You should do the following. First, cite the code in your paper, but remove the actual URL and, instead say "link to repository removed for double blind review" or similar. Second, if when writing your author response, you believe reviewer access to your code would help, say so in your author response (without providing the URL), and send the URL to the Program Chair. Third, you are strongly encouraged to submit your work to the Artifact Evaluation track.

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: Not necessarily. The core question is really whether the system is one that, once identified, automatically identifies the author(s) and/or the institution. If the system is widely available and open-sourced, and especially if it has a substantial body of contributors and has been out for a while, then these conditions may not hold (e.g., LLVM or HotSpot), because there would be considerable doubt about authorship. By contrast, a paper on a modification to a proprietary system (e.g., Visual C++, or a research project that has not open-sourced its code) implicitly reveals the identity of the authors or their institution. If naming your system essentially reveals your identity (or institution), then you must anonymize it. In your submission, point out that the system name has been anonymized. If you have any doubts, please contact the PC Chair.

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 PLDI 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 or ERC about your work (unless they are conflicted out anyway), posting mail to a major mailing list (e.g. TYPES) announcing your paper, or posting about it on social media. 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/ERC 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 Program Chair.

Q: Will the fact that PLDI is double-blind have an impact on handling conflicts-of interest?
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. Quoting (with slight alteration) from the ACM SIGPLAN review policies document:
A conflict of interest is defined as a situation in which the reviewer can be viewed as being able to benefit personally in the process of reviewing a paper. For example, if a reviewer is considering a paper written by a member of his own group, a current student, his advisor, or a group that he is seen as being in close competition with, then the outcome of the review process can have direct benefit to the reviewer's own status. If a conflict of interest exists, the potential reviewer should decline to review the paper.

For reviewers

Q: What should I do if I if I learn the authors' identity? What should I do if a prospective PLDI 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 Program 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 Program 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 and ERC 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).

These guidelines were originally created by Michael Hicks for POPL 2012, slightly modified for PLDI 2012 by Frank Tip. They were shortened by Keshav Pingali for PLDI 2014, and modified slightly by Steve Blackburn for PLDI 2015.

Instructions for Submission to PLDI’16

This document provides instructions for submitting papers to PLDI. In an effort to respect the efforts of reviewers and in the interest of fairness to all prospective authors, we request that all submissions to PLDI follow the formatting and submission rules detailed below. Submissions that violate these instructions may not be reviewed, at the discretion of the program chair, in order to maintain a review process that is fair to all potential authors.

The committee will make every effort to judge each submitted paper on its own merits. There will be no target acceptance rate. We expect to accept a wide range of papers with appropriate expectations for evaluation — while papers that build on significant past work with strong evaluations are valuable, papers that open new areas with less rigorous evaluation are equally welcome and especially encouraged. In either case, what is important is that the paper’s claims are no stronger than what is supported by the evaluation. Given the wide range of topics covered by PLDI, every effort will be made to find expert reviewers.

All questions regarding paper formatting and submission should be directed to the program chair.

The paper submission site is here.


  • Paper must be submitted in printable PDF format.
  • Text must be in a minimum 10pt font (not 9pt).
  • Submissions are double blind (see the FAQ on double blind reviewing or click on the FAQ tab above)
  • Papers must be at most 11 pages in US letter format, not including references.
  • No additional appendices (beyond 11 pages) are allowed in the paper submission, but may be included as supplemental material (see the FAQ for Double-Blind).
  • There is no page limit for references.
  • Each reference must specify all authors (no et al.).
  • Proceedings may appear in the ACM digital library as early as May 30, 2016.
  • Note that unlike last year, there will not be lightning presentations or posters for all papers.

Submission Preparation Instructions


You should specify the names and institutions that represent actual conflicts of interest. These include PhD advisors, PhD advisees, the institutions of any of the authors, any institutions or researchers with a financial conflict of interest, close friends or relatives, and any recent co-authors of papers or grant proposals (in the last 2 years). No other conflicts may be declared. The listing of spurious conflicts (especially of potential reviewers without actual conflicts, as described above) will lead to rejection of paper(s) without review.

Submission Formatting

Papers must be submitted in PDF format and follow the standard two-column ACM proceedings style in 10-point font and be at most 11 pages, exclusive of the bibliography. The bibliography is excluded from the page count to encourage good citation practices and discourage illegible bibliographies. Citations can be either in numeric style or author-year style. Numeric citations always stand as a parenthetical note (e.g., “[42]”), while author-year citations may stand either as a noun phrase (e.g., “Church (1935)”), or as a parenthetical note (e.g., “(Church, 1935)”).

If you are using LaTeX to typeset your paper, then we strongly suggest that you use this temporary LaTeX class file (with the ‘pldi’ class option) and template. If you are using Microsoft Word, you may wish to use this template, which is closely based on Friedrich Steimann’s SIGPLAN template.


Double Blind

Reviewing will be double blind; therefore, please do not include any author names or links to author’s website, etc. on any submitted documents except in the space provided on the online submission form. Please take time to read the PLDI FAQ on Double Blind Reviewing, which gives a more comprehensive and authoritative account than this short paragraph. If you are improving upon your prior work, refer to your prior work in the third person and include a full citation for the work in the bibliography. For example, if you happened to be Collins and McCarthy, building on your own prior work, you might say something like: “While prior work [Backus et al. 1960; Collins 1960; McCarthy 1960] did X, Y, and Z, this paper additionally does W, and is therefore much better.” Do NOT omit or anonymize references for blind review.

In general, you should aim to reduce the risk of accidental unblinding. For example, if your paper describes a system with a well-known name or codename, or you use a personally-identifiable naming convention for your work, you must use a different name for your submission (which you may indicate has been changed for the purposes of double-blind reviewing). You should also avoid revealing the institution where the work was performed.

Figures and Tables

Ensure that the figures and tables are legible. Please also ensure that you refer to your figures in the main text. Many reviewers print the papers in gray-scale. Therefore, if you use colors for your figures, ensure that the different colors are highly distinguishable in gray-scale.


There is no length limit for references. Each reference must explicitly list all authors of the paper. Papers not meeting this requirement will be rejected. Authors of NSF proposals should be familiar with this requirement. Knowing all authors of related work will help find the best reviewers. Authors are encouraged (but not required) to include DOIs in their references. Hyperlinked DOIs make the referenced work much more accessible to the reader and greatly assist automatic document analysis.

Paper Submission Instructions

Declaring Authors

Enter all authors of the paper into the online paper submission tool upfront. Addition/removal of authors once the paper is accepted will have to be approved by the program chair, since it potentially undermines the goal of eliminating conflicts for reviewer assignment.

Concurrent Submissions and Workshops

By submitting a manuscript to PLDI, authors guarantee that they are adhering to the SIGPLAN Republication Policy. Please ensure that you are familiar with it. Violation of any of these conditions will lead to rejection.

As always, if you are in doubt, it is best to contact the program chair.

Finally, we also note that the ACM Plagiarism Policy covers a range of ethical issues concerning the misrepresentation of other works or one’s own work.

Early Access in the Digital Library

The PLDI proceedings may be available on the ACM Digital Library as early as May 30, 2016. Authors must consider any implications of this early disclosure of their work before submitting their papers.


This document is based heavily on ones prepared for previous conferences and we thank their program chairs; in particular, Sandhya Dwarkadas (ASPLOS’15), Sarita Adve (ASPLOS’14), Steve Keckler (ISCA’14), Christos Kozyrakis (Micro’13), Margaret Martonosi (ISCA’13), Onur Mutlu (Micro’12), Michael L. Scott (ASPLOS’12), and Steve Blackburn (PLDI’15).


J. W. Backus, F. L. Bauer, J. Green, C. Katz, J. McCarthy, A. J. Perlis, H. Rutishauser, K. Samelson, B. Vauquois, J. H. Wegstein, A. van Wijngaarden, and M. Woodger. Report on the algorithmic language ALGOL 60. Commun. ACM, 3(5):299– 314, May 1960. ISSN 0001-0782. doi: 10.1145/367236.367262.

G. E. Collins. A method for overlapping and erasure of lists. Commun. ACM, 3(12):655–657, December 1960. doi: 10.1145/367487.367501.

L. Lamport. LaTeX: A Document Preparation System. Addison- Wesley, Reading, Massachusetts, 2nd edition, 1994.

J. McCarthy. Recursive functions of symbolic expressions and their computation by machine, part I. Commun. ACM, 3(4): 184–195, April 1960. doi: 10.1145/367177.367199.