Demonstration venue · read-only. Every page can be browsed; the buttons that would change it are switched off. Create an account to run TaxoReview on your own data. A simulation from public publication records: the people listed were not invited and did not agree to review.
? Tutorial for this page

Emil Tsalapatis

dblp:294/0842 · DBLP profile ↗
← Back
3ranked-venue papers
3as first author
3since 2021 · last 2024
0000-0003-2185-2029ORCID · corroborated

Domains — the database's venue-derived domains; a paper can count in several

Software engineering, systems software and programming languages · 3 · 3 first-author · 3 since 2021Systems, architecture and hardware · 1 · 1 first-author · 1 since 2021

Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.

Computer architecture, parallel and distributed computing, and storage systems
2 papers
Memory systems · 71% Storage systems · 29%
Software engineering, system software, and programming languages
2 papers
Operating systems · 100%

Topics — the 6 heaviest of 6, each with the papers that count most for it

TopicWeightPapersLastEvidence papers
Operating systems › fault tolerance
checkpoint and rollback
0.812024
MemSnap μCheckpoints: A Data Single Level Store for Fearless Persistence · ASPLOS (3) 2024
Memory systems › memory management
single level store
0.812024
MemSnap μCheckpoints: A Data Single Level Store for Fearless Persistence · ASPLOS (3) 2024
Operating systems › resource management › memory management › virtual memory
single-level store
0.512021
The Aurora Single Level Store Operating System · SOSP 2021
Storage systems › logging
write-ahead logging
0.212024
MemSnap μCheckpoints: A Data Single Level Store for Fearless Persistence · ASPLOS (3) 2024
Storage systems
file systems
0.112021
The Aurora Single Level Store Operating System · SOSP 2021
Memory systems › non-volatile memory
persistent memory
0.112021
The Aurora Single Level Store Operating System · SOSP 2021

Methods — techniques the papers use, named apart from their topics

data checkpointing · 1.5
YearPublicationVenuePosition
2024 MemSnap μCheckpoints: A Data Single Level Store for Fearless Persistence
abstract
Single level stores (SLSes) have recently resurfaced as a system for persisting application data. SLSes like EROS, Aurora, and TreeSLS use application checkpointing to replace file-based APIs. These systems checkpoint at a coarse granularity and must be combined with file persistence mechanisms like WALs, undermining the benefits of their SLS design.
Emil Tsalapatis, Ryan Hancock, Rakeeb Hossain, Ali José Mashtizadeh
ASPLOS (3)1
2021 The Aurora operating system: revisiting the single level store
abstract
Applications on modern operating systems manage their ephemeral state in memory, and persistent state on disk. Ensuring consistency between them is a source of significant developer effort, yet still a source of significant bugs in mature applications. We present the Aurora single level store (SLS), an OS that simplifies persistence by automatically persisting all traditionally ephemeral application state. With recent storage hardware like NVMe SSDs and NVDIMMs, Aurora is able to continuously checkpoint entire applications with millisecond granularity.
Emil Tsalapatis, Ryan Hancock, Tavian Barnes, Ali José Mashtizadeh
HotOS1
2021 The Aurora Single Level Store Operating System
abstract
Applications on modern operating systems manage their ephemeral state in memory and persistent state on disk. Ensuring consistency between them is a source of significant developer effort and application bugs. We present the Aurora single level store, an OS that eliminates the distinction between ephemeral and persistent application state.
Emil Tsalapatis, Ryan Hancock, Tavian Barnes, Ali José Mashtizadeh
SOSP1