/asplos-topic-selection

name: asplos-topic-selection
description: Use when deciding whether a project belongs at ASPLOS or at a single-community venue — applying the cross-layer deletion test, matching against ASPLOS's architecture/PL/OS intersection identity, routing to ISCA/MICRO/HPCA, PLDI/POPL, SOSP/OSDI/EuroSys, SC, or MLSys instead, and choosing between the April and September deadlines.

ASPLOS Topic Selection

ASPLOS's self-description is unusually operational: it seeks work that improves the core disciplines — operating systems, programming languages, computer architecture — **and their intersection**, and its 2027 rapid-review round explicitly prioritizes submissions at that intersection (CFP, checked 2026-07-08). Venue fit is therefore not a prestige question here; it is a screening variable. A technically strong paper that lives cleanly inside one community can be filtered in the first round not because it is bad but because a single-community venue owns its reviewers.

The deletion test

Ask, for each layer the paper touches: *if this layer's content were deleted, would a publishable paper remain?*

• Delete the software half and a full paper remains → the work is an ISCA/MICRO/HPCA

candidate wearing an ASPLOS template.

• Delete the hardware half and a full paper remains → it is a SOSP/OSDI/EuroSys or

PLDI paper.

• Delete either half and *nothing defensible remains* → the coupling is real; ASPLOS

is a first-choice target.

The exemplars library shows what passing looks like in award-validated form: an accelerator argued from data movement, a scheduler premised on hardware heterogeneity, an interrupt-delivery boundary redrawn between hypervisor and silicon (see `../../resources/exemplars/library.md`).

Routing table

| If the core claim is... | Stronger first target | ASPLOS becomes right when... | |---|---|---| | A microarchitectural structure (predictor, cache policy, pipeline) | ISCA / MICRO / HPCA | The structure exists to serve a named software behavior, and software changes with it | | A language design, type system, or compiler optimization | PLDI / POPL / CGO / OOPSLA | The compiler co-evolves with an ISA, accelerator, or OS interface | | An OS/distributed-systems design on commodity hardware | SOSP / OSDI / EuroSys / ATC | Hardware assumptions are load-bearing: new memory technology, custom hints, near-data compute | | HPC-scale performance engineering | SC / PPoPP | The result generalizes into an architectural or systems principle beyond one machine | | ML training/serving systems on stock stacks | MLSys | The ML workload drives a hardware/software interface change, not just better scheduling | | Security via hardware mechanisms | IEEE S&P / USENIX Security / CCS | The defense requires co-designed architecture + systems support and its evaluation is performance-shaped |

Scope confirmation: the 2027 topics list spans heterogeneous architectures and accelerators; cloud and datacenters; memory, storage, networking, and I/O; power, energy, and thermal management; profiling, debugging, and testing; security, reliability, and availability; parallelism and big-data systems; virtualization; and experimental methodologies — with non-traditional topics welcome when centered in the core disciplines.

Fit interrogation script

Run this before any writing begins:

Q1  Name the interface/boundary the work changes (ISA extension, OS/hardware
    contract, runtime/accelerator ABI, ...). No boundary named -> weak fit.
Q2  Deletion test per layer (above). Both halves survive alone -> route away.
Q3  Who must adopt this? If one community can adopt it without the other
    noticing, the intersection claim is decorative.
Q4  What evidence class does the claim need — real silicon, FPGA, simulator?
    If the answer is "none of these", the paper may be a PL/theory paper.
Q5  Can the contribution be stated in one sentence that a rapid reviewer
    reading only two pages will believe? Draft that sentence now.

Choosing between the two 2027 deadlines

ASPLOS 2027 offers two submission gates — April 15, 2026 (passed as of 2026-07-08) and **September 9, 2026** — framed by the CFP as "submit when ready." Treat the choice as an evidence-maturity decision, not a calendar accident:

• Submit September only if the evaluation matrix is complete; the two-deadline model

removed the mid-year round, so a miss costs roughly half a year.

• A Major Revision outcome effectively adds a private third gate (revision due at the

camera-ready deadline, six weeks after notification) — but only for papers whose core was sound. Do not submit a hollow evaluation hoping for the revision path; the revision counts as a submission on your record with that PC.

Distinctive-fit signals worth writing down

• The paper's insight is *information that crosses a layer* (what hardware knows that

software needs, or vice versa) — the most reliably ASPLOS-shaped idea.

• The evaluation needs both a hardware-accuracy instrument (simulator/FPGA/silicon)

and a software-realism instrument (kernel patch, runtime, full applications).

• Related work must be argued against two or three communities at once; if one

community's literature suffices, so would its venue.

Intersection anti-patterns

Recurring shapes that look ASPLOS-flavored but fail the screen:

• **The garnish paper** — a complete single-community design plus one paragraph

of "hardware support could accelerate this." The intersection must be load-bearing on page 1, not speculative in section 8.

• **The stapler paper** — an architecture result and an OS result about the same

workload, bound in one PDF with no shared mechanism. Two rejectable halves do not sum to one acceptable whole.

• **The tuning paper** — heroic performance engineering on existing interfaces.

Without a changed boundary or a transferable principle, it routes to ATC-style venues or an industrial track.

• **The premature-generality paper** — a mechanism evaluated