ASPLOS, the ACM International Conference on Architectural Support for Programming Languages and Operating Systems, is the premier academic forum for multidisciplinary computer systems research spanning hardware, software, and their interaction. It focuses on computer architecture, programming languages, operating systems, and associated areas such as networking and storage. ASPLOS 2024 will take place in April 2024 in California. It has three submission deadlines – spring, summer and fall – which are meant to encourage authors to submit their papers when they are ready rather than before. Also, as an alternative to rejection, ASPLOS 2024 will allow the authors of some submissions to choose to apply a major revision to their submission in order to fix a well-defined list of problems.
Important Dates and Submission Sites
|author response period start||2023-07-11||2023-10-24||2024-02-13|
|author response period end||2023-07-13||2023-10-26||2024-02-15|
Scope and Expectations
The scope of ASPLOS 2024 covers all practical aspects related to the three main ASPLOS disciplines: computer architecture, programming languages, and operating systems, as well as closely-related associated areas. We seek original, high-quality research submissions that improve and further the knowledge of computer systems, with emphasis on the intersection between the main ASPLOS disciplines. Research submission may be applicable to computer systems of any scale, ranging from small, ultra-low power wearable devices to exascale parallel and cloud computers. We embrace research that directly targets new problems in innovative ways. The research may target diverse goals, such as performance, energy, and security. Non-traditional topics are encouraged, and the review process will be sensitive to the challenges of multidisciplinary work in emerging areas. We welcome experience submissions that have a novel aspect and that clearly articulate the lessons learned. We likewise welcome submissions that convincingly refute prior published results and common wisdom. We value submissions more highly if they are accompanied by clearly defined artifacts not previously available, including traces, original data, source code, or tools developed as part of the submitted work. We particularly encourage new ideas and approaches.
Alphabetically sorted areas of interest related to practical aspects of computer architecture, programming languages, and operating systems include but are not limited to:
- Existing, emerging, and nontraditional compute platforms at all scales
- Heterogeneous architectures and accelerators
- Internet services, cloud computing, and datacenters
- Memory, storage, networking, and I/O
- Power, energy, and thermal management
- Profiling, debugging, and testing
- Security, reliability, and availability
- Systems for enabling parallelism and computation on big data
- Virtualization and virtualized systems
A good submission will typically: motivate a significant problem; propose a practical solution or approach that makes sense; demonstrate not just the pros but also the cons of the proposal using sound experimental methods; explicitly disclose what has and has not been implemented; articulate the new contributions beyond previous work; and refrain from overclaiming, focusing the abstract and introduction sections primarily on the difference between the new proposal and what is already available. Submissions will be judged on relevance, novelty, technical merit, and clarity. Submissions are expected to avoid committing “benchmarking crimes,” and they must follow all the policies specified below.
Authors of resubmitted work should describe in a separate note – uploaded to the submission site – the changes since the previous submission(s). This description helps reviewers who may have reviewed a previous draft of the work to appreciate any improvements to the currently submitted work. Please try to limit this document to one page.
Submissions rejected from ASPLOS must not be submitted to the next two subsequent review cycles. The following table details when ASPLOS ’23 and ASPLOS ’24 rejections can be resubmitted to ASPLOS ’24 and ASPLOS ’25.
|if rejected from||must not resubmit to||may resubmit to|
|2023 spring||–||2024 spring or later|
|2023 summer||2024 spring||2024 summer or later|
|2023 fall||2024 spring & summer||2024 fall or later|
|2024 spring||2024 summer & fall||2025 spring or later|
|2024 summer||2024 fall & 2025 spring||2025 summer or later|
|2024 fall||2025 spring & summer||2025 fall or later|
Major Revision Option
When the outcome of a review cycle is publicized, some submissions will be associated with a “revise and resubmit” decision. The authors of such submissions will be given the opportunity to apply a major revision to their work and resubmit it after around 6 weeks. These submissions will be provided with clear and actionable reviewer feedback for their revision, and they will be typically reviewed by the same reviewers as the original submission. If the revision requirements are satisfactorily met, the revised submission will be accepted.
ASPLOS employs a double-blind review process, keeping author identities concealed from reviewers and vice versa. You must therefore make a good faith attempt to anonymize your submission by avoiding identifying yourself or your institution/affiliation in any of the submitted documents (except in specific fields on the HotCRP submission form designated for this purpose), either explicitly or by implication, e.g., through references, acknowledgments, online repositories that are referenced by the submission, or interaction with committee members.
Do not include a “reference removed for blind review” text or similar in your submission. When it is necessary to cite your own studies, there are only two possibilities: cite them preferably (1) as written by a third party; or, if that is not possible, (2) as uploaded anonymized supplemental material (see below). This guideline applies in particular to any of your workshop papers that are being extended by your current ASPLOS submission. Related submissions of your own that are simultaneously under review or awaiting publication at other venues should typically opt for the second option. Publication as a technical report or in an online repository does not constitute a violation of this policy, and some other exceptions apply; see the “originality and concurrent submissions” section below for details.
Please make sure not to reveal author and/or affiliation information through side channels and other less obvious means. For example, the metadata included in the PDF should not give away such information. If you’d like to point to a repository of, e.g., the working code of your system (which is great and much appreciated), this repository should, of course, be anonymized. It is okay and often makes sense to create anonymized repositories merely for the sake of an anonymous submission. If your system is already released to the public, rename it in your submission. You should likewise avoid inadvertently revealing affiliation in your submission by identifying your company’s name in situations where, e.g., it is clear that the authors of the submission most probably work for the company that manufactures the device or provides the service that constitutes the topic of your work; instead, please use a generic name, like “a computer server vendor X,” “a cloud service provider Y,” and such like.
If concealing system name or affiliation would make your paper difficult to understand, contact the program chairs to discuss exceptions to this policy. Submissions that are not properly anonymized will likely be rejected without review.
Anonymized Supplemental Material
Supplemental material may be submitted as a single-but-separate anonymized PDF file without page limit. The nature of such material is explained in the above “anonymizing” section. Note that the reviewers are not required nor encouraged to read such material when making their decision. Any material that should be considered to properly judge the submission for acceptance or rejection is not to be treated as supplemental and applies to the page limit.
Declaring Conflicts of Interest
Authors must register all their conflicts in their HotCRP submission page. Conflicts are needed to ensure appropriate assignment of reviewers. If a submission is found to have an undeclared conflict that causes a problem OR if a paper is found to declare false conflicts in order to abuse or “game” the review system, the submission will be summarily rejected.
Both people and institutions (companies, universities, and other relevant organizations) may be declared as having a conflict of interest (COI) with respect to an author. Please declare a COI with the following for any author of your submission; please do so with respect to all your conflicts, not just restricted to program committee (PC) and extended review committee (ERC) members, as we may occasionally ask for external reviews from people outside the PC/ERC.
- Your current institution(s) and other institutions that you were affiliated with in the past four years relative to the submission deadline; also, an institution that is about to become your employer.
- Your PhD advisor(s), post-doctoral host(s), PhD students, and post-doctoral advisees; these COIs are forever.
- Family relations by blood or marriage and close personal friends (who may potentially be reviewers); these COIs are likewise forever.
- People with whom you have collaborated in the last four years, including co-authors of accepted/rejected/pending paper submissions and co-PIs of accepted/rejected/pending grant proposals.
- Potential reviewers who shared your primary institution(s) in the last four years, or where one is actively engaged in discussions about employment with the other person’s institution.
- When there is a direct funding relationship between an author and a potential reviewer (e.g., the reviewer is a sponsor of an author’s research on behalf of his/her company or vice versa).
- Among PIs of research structures supported under the same umbrella funding award who (1) participate regularly in non-public meetings sponsored by that umbrella award, and (2) are regularly exposed to presentations or discussions of unpublished work at such meetings.
Do not declare a COI for the following cases:
- You must not declare a COI with a reviewer just because that reviewer works on topics similar to or related to those in your paper.
- “Service” collaborations such as co-authoring a report for a professional organization or an open-source community, serving on a program committee, or co-presenting tutorials, do not themselves create a COI.
- Co-authoring a paper that is a compendium of various projects without direct collaboration among the projects does not constitute a conflict among the authors of the different projects.
- Internships constitute a conflict of interest during the period of employment of the intern, but not thereafter, unless some other provision applies (e.g., co-authorship or ongoing research collaboration after the internship). Graduate students are not presumed to have an automatic COI with their undergraduate institution. On the other hand, prospective graduate students do have a COI with any institution they have applied to if they are actively engaged in discussions with any faculty member at that institution. Once they join an institution to pursue graduate studies, automatic COIs with any other prospective institutions sunset. In all these cases, the collaboration COI above still applies.
When in doubt, contact the program chairs and ask.
Declare all the authors of the submission upfront. Addition/removal of authors once the submission is accepted will have to be approved by the program chairs, since it potentially undermines the goal of eliminating conflicts for reviewer assignment.
Declaring Areas and Topics
ASPLOS emphasizes multidisciplinary research. Submissions should ideally – albeit not necessarily – emphasize synergy of two or more of the three main ASPLOS disciplines: computer architecture, programming languages, and operating systems (broadly interpreted). Authors should therefore indicate at least one of these areas on the submission form and, preferably, more than one.
Authors should also indicate on the submission form more focused topics matching their work, which will be used for reviewer assignment.
Originality and Concurrent Submissions
By submitting a manuscript to ASPLOS, the authors guarantee that the manuscript has not been previously published or accepted for publication in a substantially similar form in any conference, journal, or workshop. The only exceptions are (1) workshops without archived proceedings such as in the ACM digital library (or where the authors chose not to have their paper appear in the archived proceedings), or (2) venues such as IEEE CAL where there is an explicit policy that such publication does not preclude longer conference submissions. These are not considered prior publications. Technical reports and papers posted on public social media sites, web pages, or online repositories such as arxiv.org are not considered prior publications either. In these cases, the submitted manuscript may ignore the posted work to preserve author anonymity.
The authors additionally guarantee that no manuscript that contains significant overlap with the contributions of the submitted document is or will be under review for any other conference, journal, or workshop during the ASPLOS review cycle for which it was submitted. Violation of any of these conditions will lead to rejection and possibly additional actions against the offending authors.
You should also adhere to the ACM Plagiarism Policy (http://www.acm.org/publications/policies/plagiarism_policy), which covers a range of ethical issues concerning the misrepresentation of other works or one’s own work.
As usual, if in doubt, consult with the program chairs.
Ethical and Other Obligations
- Authors are not allowed: to contact reviewers or PC/ERC members in order to encourage or solicit them to bid on any submission; to attempt to sway a reviewer or PC/ERC member to review any submission positively or negatively; to contact reviewers or PC/ERC members requesting any type of information about the reviewing process, either in general or specifically about submitted manuscripts; to contact reviewers or PC/ERC members to ask about the outcomes of any submission.
- Authors are not allowed to advertise their submissions or related technical reports and postings (e.g., to arxiv.org or online repositories) on social media or community blogs and web pages during the period starting two weeks before the submission deadline and ending when the results of the corresponding review cycle are publicized.
- Authors are not allowed to post in the aforementioned channels about the content of the reviews they may have received until the results of the corresponding review cycle are publicized; “shaming” (and thus potentially applying pressure on) reviewers before the review process terminates is considered unethical.
- Authors must abide by the ACM ethics policy (https://www.acm.org/code-of-ethics).
Violation of these policies might result in rejection of the submission and possible additional action by the ACM.
ACM requires that all submitting authors will be aware of the following policies in particular:
By submitting your article to an ACM publication, you are hereby acknowledging that you and your co-authors are subject to all ACM Publications Policies, including ACM’s new Publications Policy on Research Involving Human Participants and Subjects. Alleged violations of this policy or any ACM Publications Policy will be investigated by ACM and may result in a full retraction of your paper, in addition to other potential penalties, as per ACM Publications Policy.
Auxiliary Files. Submissions must be printable PDF files. When creating your submission, use this latex template, which will do what’s necessary, including taking care of most of the formatting details specified below. Refrain from tweaking this template and from formatting your text in a manner that violates its settings. Notably, refrain from “squeezing” additional space (e.g., with inconsiderate use of \vspace), as, in any case, the template generates a very dense document. To help you with formatting your submission, we have provided a sample paper that meets the ASPLOS 2024 requirements. Your submission should be visually similar. The latex template, sample paper, and some other relevant files that will allow you to regenerate the sample paper can be found in this zip file.
Page Layout and Limit. Full submissions must not exceed 11 pages of single-spaced two-column text. This page limit applies to all text, figures, tables, footnotes, appendices, etc. Bibliographic references are not included in the page limit. The reviewers greatly value conciseness, so if you can describe your work with fewer pages than the limit, please do. All pages should be numbered.
Font Size, Tables, and Figures. The submission’s text must use a 10pt font (not 9pt) or bigger. Labels, captions, and text within figures, graphs, and tables must use reasonable font sizes that, as printed, do not require extra magnification beyond “100%” to be legible. In particular, text inside figures/tables should generally use what appears to readers as a 9pt font or bigger after any intra-document scaling has been applied. Fonts appearing smaller than 8pt are not permitted (this requirement, however, is not checked automatically by submission to HotCRP, so it is the authors’ responsibility to check it). Figures can and should use colors but should also be color-blind friendly and readable when printed in monochrome. Spacing between figures/tables/captions/text should be determined by the latex template.
References. Because references do not count against the page limit, the space they occupy should not be “optimized” away. Notably, the full, non-abbreviated first and last names of all co-authors of all citations must be specified (no “et al.”). The reference citations within the submission (numbers in square brackets) should be hyperlinked to the corresponding items in the references section, to ease the job of reviewers. Also, reviewers will very much appreciate clickable links (preferably DOIs) associated with each entry in your references section.
Specifications. The following table specifies some of the main typeset requirements. Use our latex template and follow the above instructions to make sure that these and other formatting requirements are met.
|file format||PDF with numbered pages|
|page limit||11 pages, not including references|
|paper size||US Letter 8.5in x 11in|
|body font size||10pt|
|abstract font||10pt, italicized|
|section heading font||12pt, bold|
|subsection heading font||10pt, bold|
|space between section heading and text||≥ 6pt|
|fonts in figures and tables||≥ 8pt, preferably ≥ 9pt|
|reference entries||8pt; no page limit; list full names of all author (no “et al.”); include link to document (preferably DOI); make references to citations clickable|
|appendices||count towards the page limit|
Author Response Period
ASPLOS 2024 will provide an opportunity for authors to respond to reviews prior to final consideration of the submissions at the program committee meeting; see exact dates specified above. Authors should limit their response rebuttal to: (1) correcting factual errors in the reviews; and (2) directly addressing questions posed by reviewers. Rebuttals should be limited to clarifying the submitted work rather than include new experiments/data or describe additional work completed since the submission. Rebuttals are optional but strongly encouraged. There is no explicit word limit to a rebuttal, but authors are strongly encouraged to keep it under 1500 words, and reviewers are not expected to read words that exceed this limit.
Submissions selected by the program committee will be conditionally accepted, subject to revision and approval by a committee member acting as a shepherd. Accepted papers will be allowed an additional page in the proceedings. We expect that one author of each accepted paper will physically attend the conference and present the work in a dedicated time slot (unless all authors have difficulty traveling due to such serious limitations as visa restrictions, care-giving responsibilities, and disability). By default, all accepted papers will be made available online to registered attendees before the conference at a date that depends on the review cycle. Papers accepted to the spring and summer deadlines will be published in separate volumes in advance of the conference.
ACM requires that all authors of accepted papers will adhere to the following policy. Please ensure that you and your co-authors obtain an ORCID ID, so you can complete the publishing process for your accepted paper. ACM has made a commitment to collect ORCID IDs from all published authors to improve author discoverability, ensure proper attribution, and contribute to ongoing community efforts around name normalization; your ORCID ID will help in these efforts.
Artifact evaluation will continue in 2024 as has become a tradition at ASPLOS. More details will become available later.
Poster and Lightning Sessions
In addition to the regular presentations, the program will also tentatively include poster and lightning sessions. In the poster session(s), at least one author of every accepted paper is expected to present a poster summarizing their work. In the lightning session(s), one author of every accepted paper will present their work in a 120-second “lightning talk,” and a corresponding lightning video should be submitted to appear on the conference site in advance of the conference.
Details will become available later.
Wild and Crazy Ideas Session
The program will also tentatively include a WACI session. Details will become available later.
The program will additionally tentatively include a debate session. Details will become available later.
Best Paper Award
The committee will select a handful of papers to receive a Best Paper Award. The decision may or may not be communicated to the winning authors prior to the official announcement at the opening session of the conference.
Program and Registration
Complete program and registration information will be available on the conference website as soon as it becomes available.
All submissions will be treated as confidential prior to publication. Rejected submissions will be permanently treated as confidential.
Several ideas in this document and parts of the text have been taken from previous conferences, so we thank their program chairs. In particular, Natalie Enright Jerger and Michael Swift (ASPLOS ’23), Shan Lu and Thomas Wenisch (ASPLOS ’22), Emery Berger and Christos Kozyrakis (ASPLOS ’21), Luis Ceze and Karin Strauss (ASPLOS ’20), Emmett Witchel and Alvy Lebeck (ASPLOS ’19), Dahlia Malkhi and Dan Tsafrir (ATC ’19), Ricardo Bianchini and Vivek Sarkar (ASPLOS ’18), John Carter (ASPLOS ’17), Yuanyuan Zhou (ASPLOS ’16), Sandhya Dwarkadas (ASPLOS ’15), Sarita Adve (ASPLOS ’14), Steve Keckler (ISCA ’14), Margaret Martonosi (ISCA ’13), Onur Mutlu (MICRO ’12), and Michael L. Scott (ASPLOS ’12).
Nael Abu-Ghazaleh (University of California, Riverside)
Rajiv Gupta (University of California, Riverside)
Madan Musuvathi (Microsoft Research)
Dan Tsafrir (Technion & VMware Research)
Michael Ferdman (Stony Brook University) – Chair
Emery Berger (University of Massachusetts Amherst)
Babak Falsafi (EPFL)
Jeff Foster (Tufts University)
Natalie Enright Jerger (University of Toronto)
Christos Kozyrakis (Stanford University)
Shan Lu (University of Chicago)
Tim Sherwood (University of California, Santa Barbara)
Michael Swift (University of Wisconsin, Madison)
Thomas Wenisch (Google & University of Michigan)
Please direct any questions to the program co-chairs at firstname.lastname@example.org.